DevinAPIを利用して、PR単位でテストケースを生成する

こんにちは！最近はSDET（Software Development Engineer in Test）を自称しようと思っている山本（yama-chan）です！

今回はプロダクトチームで試験的に導入している、DevinAPIを利用して、PR単位でテストケースを自動生成する取り組みを紹介できればと思います！

初めに

estieのQAチームは「高速な価値提供サイクルの支えになる」をミッションに、プロダクトの品質を保ちつつ、高速な開発サイクルを支援するための取り組みを考えています。

そのためにもAIにたくさん働いてもらう必要があり、日々雑談レベルでAIで何か効率化できることがなさそうかを会話しています。

PRに対してテストケースAIに考えてもらえたらいいことあるかも？という話があり、実際にDevinAPIを使って実装してみたらよさそうだったので、その話を共有しようと思います。

取り組んだこと

DevinAPIとGithubActionsを利用して、ラベルをトリガーとして、PRに対してテストを生成してコメントさせる仕組みを導入しました。

前提

estieの開発では、Preview環境という仕組みが導入されており、PRに対して気軽に検証環境を立てることができます。

機能実装の動作検証はPR単位で行っており、小さく開発してリリースすることで、高速な開発サイクルを実現しています。

現状AIを利用して、開発サイクル自体は高速になっているのですが、コードレビューや動作検証は人間の手で行っており、ボトルネックになりやすい範囲です。

ただ、この分野をすべてAIに任せてしまうと、インシデントのリスクが上がってしまうという現実もあります。

そこで、AIを活用してテストケースの作成を高速化しつつ、人間の目で見てしっかりと結果を確認するという開発サイクルを取ることにしました。

DevinAPI

今回は上記を実現するために、Devinを活用してみることにしました。

自前でagentを実装するという方法もあると思うのでうすが、Devinを利用すると以下のメリットがあると考えています。

導入コストが低い
- プロダクトですでにDevinを導入している場合は、そのまま環境構築などすることなく導入することができます。
Devinが賢くなれば、テストケースの精度も上がる。
- 自前でagentを実装した場合、テストケースの精度を向上させるためには継続的にシステムプロンプトを改善することが求められます。AIの精度の向上もDevin側に委譲できるので、継続的なコストも削減できます。

費用面や外部APIならではの制約がある部分もありますが、導入コストが低いということで一旦導入してみることにしました（思いつきの実装だったので、導入時はここまで考えていませんでしたが、、、）

Devinが導入されていれば使い方は簡単で、

Devin (the Developer)

からAPIキーを発行するだけです。

公式ドキュメントもあるので、こちらを見て頂くのがわかりやすいかなと思います。

Create a new session - Devin Docs

実装

以下の感じで実装しています（サンプルとして簡略化しています）


name: Devin PR Review

on:
  pull_request:
    types: [labeled]

permissions:
  pull-requests: write
  issues: write

jobs:
  review:
    if: ${{ github.event.label.name == 'devin:review' }}
    runs-on: ubuntu-latest
    steps:
      - name: Validate API Key
        run: |
          if [ -z "${{ secrets.DEVIN_API_KEY }}" ]; then
            echo "APIキーが設定されていません"
            exit 1
          fi

      - name: Request Devin review
        uses: actions/github-script@v7
        env:
          DEVIN_API_KEY: ${{ secrets.DEVIN_API_KEY }}
        with:
          script: |
            const prNumber = context.payload.pull_request.number;

            // ここにプロンプトを定義する
            const body = [
              '🤖 Devinレビューを依頼しました。',
              '結果は別途コメントされます。'
            ].join('\n');

            await github.rest.issues.createComment({
              owner: context.repo.owner,
              repo: context.repo.repo,
              issue_number: prNumber,
              body
            });

プロンプトに関しては一旦以下に気を付けています。

コードの変更から、直接ではなくとも影響しそうな箇所をすべて特定する
- ライブラリアップデートなどは、ファイルとしての差分は少量になるので、影響する関数や処理まで深ぼってテストケースを考えられるようにします。
テストの重要度をつける（must, want でレベル分けしてもらう）
- AIの考えるテストケースが細かすぎる問題があり、無駄が大きくなりがちなので、人間がある程度見て重要度を判断できるように重要度をつけてもらっています。
非機能的なテストも考えてもらう
- 人間の観点だとどうしても抜け漏れが起こりやすい観点なので、明示的に指示をして考えてもらうようにしています。
テスト以外の確認事項も羅列する
- そもそもの要件や変更の意図などまでAIが踏み込んで考えられるのか？の検証の意図も含めて入れています。