AIでユニットテストを作る｜正解の根拠と境界値を確認する

この記事の内容

仕様の例を先に用意する

割引率の入力を扱う関数なら、0％、100％、負の値、上限超過、空欄をどう処理するかを先に決めます。数値の丸めや通貨が関係する場合は、具体的な入力と出力を人が確認します。その例をエージェントへ渡すと、現行実装の動作を無条件に正解にする危険を減らせます。

同じ処理を似た値で十回確認しても、重要な境界が抜けていれば防げない不具合があります。正常、境界、無効、例外のどれを守るかを整理し、ケースを重複させないようにします。テスト名には、入力だけでなく守りたい動作を書き、失敗したときに調べる場所が分かるようにします。

内部の変数名や関数の呼び出し回数だけを確認すると、動作を変えない整理でもテストが壊れることがあります。外から見た出力や必要な副作用を中心にし、内部の構造を確認する必要がある場合はその理由を明確にします。エージェントが実装とテストを同時に変えるときは、仕様の例が維持されているかを特に注意して見ます。

不具合修正のテストなら、修正前のコードで失敗し、修正後に成功することを確認すると意味が分かりやすくなります。意図的に重要な条件を一つ変えたときにテストが反応するかを見る方法もあります。何を変えても通るテストは、実行環境だけを確認している可能性があるため、期待値や検証対象を見直します。

架空の計算として、1000円に10％の割引を適用した結果を900円と決めます。次に0％、100％、無効な値でどうするかを定義します。この期待値は製品の公式価格ではなく、テストのための仕様例です。AIには例を満たすテストを作ってもらい、丸め方や入力エラーの扱いを勝手に追加していないかを確認します。

Claude Code、Cline、Aiderなどを使う場合も、実行コマンド、対象テスト、実行結果、確認していない条件を残します。外部APIをモックに置き換えたテストでは、実際の接続まで確認したとは書かないでください。テストの追加件数だけでなく、どの仕様を守るようになったかをレビューで説明します。

料金・提供条件・対応範囲は変更されることがあります。契約前に、下記の公式ページでご確認ください。