AIを用いた、ユニットテストを書く際の手順（2025/07版）

前置き

最近、ユニットテストの作成にAIを活用する際の手順を、ある程度、定型化出来てきた気がするので、その共有です

Laravelプロジェクトでの実装を前提としており、PHPUnitを使用したテスト環境での運用を想定しています。

手順

1. LaravelのプロジェクトでPHPUnitのカバレッジを出すようにする

composer.jsonに以下のスクリプトを追加します：

{
  "scripts": {
    "test:coverage": "vendor/bin/phpunit -d memory_limit=-1 --coverage-html=code-coverage --configuration phpunit.xml ./tests"
  }
}

カバレッジを取得するためのコマンドを実行します：

COMPOSER_PROCESS_TIMEOUT=0 XDEBUG_MODE=coverage DB_PORT=${任意の値} composer test:coverage -- --filter="${テスト対象ファイル名orメソッド名etc}"

2. 機能実装が完了

まず、対象となる機能の実装を完了させます。この段階では、テストコードはまだ書かれていない状態です。

3. カバレッジレポートの確認

カバレッジレポートが生成されるので、実装による変更差分のコードがカバレッジを通ってるかを確認します。

カバレッジレポート出すのに全テストケース通すと、まぁまぁ時間がかかるので、昼休み前に実行しとくとか、--filterで対象絞る、とかの工夫をするといいです。

4. AIにユニットテスト記述を依頼

カバレッジレポートを見て、テストケースの追加が必要そうなら、その該当箇所のテストコード作成を、AIに投げます。

プロンプト例：

app/Services/CalculatorService.phpのdivide()の以下の箇所で、コードカバレッジを通すためのテストを書いてほしい


        // Handle very small divisor (not covered by tests)
        if (abs($b) < 0.0001) {
            error_log("Division with very small divisor: {$a} / {$b}");
            throw new \InvalidArgumentException('Divisor too small, may cause precision issues');
        }


ほとんど、ここに来ることは無い想定だから、単純な１テストケースだけでいい。

この際の個人的なポイント：

• 対象のファイル名とコードを明示する
• 参考にしてほしい実装があれば、そのファイル名とコードを明示する
• ADR（Architecture Decision Record）的な仕様書も一緒に貼り付けると、より適切なテストが生成される

個人的にはこのくらいで、他の人に比べて、プロンプト頑張ってなくて、対話で頑張ってる気がします。
（そのせいで、トークン消費が人より多い気がしないでもない）

ちなみに、このタイミングで「PHPUNIT実行とFAILの修正」のサイクルをAIに依頼してもいいんですが、それやるとトークンがかさむ割に、FAILの修正のアウトプットが期待とずれることが多い気がしてるので、今は「PHPUNIT実行とFAILの修正」までは任せてないです。
（これはAIの進化なり、コンテキストうまく渡せば、任せれそうな気がしてるんですが）

5. 再度カバレッジを確認

再度カバレッジを出して確認し、変更差分のメインロジックがカバレッジを通していることを確認します。

個人の感想（2025/07時点）

• 「AIによるユニットテスト作成」は「AIによる機能実装」に比べて、かなりコスパタイパが良い
  • テストコードだから、PJごとだったり個人ごとの、設計とかコードの書き方のブレに、そこまで敏感にならなくていいから、AIの出力からの手戻りが少ない
  • 自分が知らない、テストフレームワークが持つ最新の機能をAIが書いてくれる
    • あくまでテストコードだから、プロダクションコードとは違って、ユーザーへの影響を鑑みた際の調査とか考察は、求められない
  • ADR的な仕様書をプロンプトで貼り付けて作ってもらうテストケースの、網羅性が自分で考えるより正しくて速い
• AIでユニットテストの生成量が増えるから、近い内に実行時間の方がボトルネックが来そう
  • 対処療法としては、テストの平行実行なりで、当面はどうにかなると思ってる
  • ただ、いつか「テストの削減が必要」が来た時に、消していいかの判断に、仕様との照らし合わせも必要そうだし、書く時よりも人の判断が要るんじゃないかな、という予感
    • ただ、それ来るのちょっと先の未来だし、その時はAIなり、より良いツールが出てそうだから、今はそこまで考えない方がいいかな、とも思ってる。
      • それ考えるよりもテスト作成の生成量アップスピードアップによる、品質アップリリース速度アップ、のが大事そう。