AIでテストコードを作る方法｜任せる範囲と確認点

AIでテストコードを作るときは、実装を読ませてそのままtestに写すのではなく、先に期待するbehaviorと不正・境界条件を決めます。実装と同じ思い込みをtestへ複製すると、バグがあってもpassすることがあります。AIにはtest caseの候補を作らせ、人が仕様と期待値を確認してからコードにし、失敗を検出できるかも試してください。

Test対象の振る舞いと境界を決める

最初に、何を確かめるtestなのか一文にします。関数の計算結果、componentの表示、APIとの契約、複数処理の連携では、適切なtestの単位が異なります。private helperやstateの内部形を固定するより、利用者や呼び出し側から確認できる結果を優先します。例えば「送信するとsuccess messageが表示される」「不正入力は保存されない」「limitを超えた条件を拒否する」のように観測可能な形にします。

正常値だけでなく、空、無効値、最小・最大、重複、NULL、権限不足、外部通信失敗などを候補にします。すべての組合せを機械的に掛け合わせるのではなく、変更のriskと仕様から優先順位を決めます。境界値の意味が不明なら、AIが決めた値を正解にせず、仕様ownerへ確認します。

Case一覧を先に作る

AIへtest codeを書かせる前に、test名、前提、操作、期待結果を表にさせます。設計をレビューすれば、実装フレームワークの詳細に隠れる前に抜けや誤解を見つけられます。

表は横にスクロールできます

条件	入力・状態	期待結果
通常	有効な値、必要な依存あり	契約どおり結果を返す
空	空文字、空配列、未設定	仕様上のempty stateを返す
境界	上限の直前・一致・超過	境界の包含条件に従う
不正	型違い、形式違い、禁止値	更新せず明示的に拒否
依存失敗	timeout、error response	回復可能なerror state
権限	未認証・権限不足	処理を許可しない

依頼例：

「この関数のimplementationをtestへ写すのではなく、公開仕様の期待動作を先に整理してください。正常値、空、境界、invalid、依存errorのcase一覧を、入力・前提・期待結果・根拠で示してください。仕様から導けない期待値は未確定として質問にし、test codeはまだ書かないでください。」

この例を使う場合も、実際の仕様や境界を代わりに決めるものではありません。ケースの根拠が仕様、既存契約、関係者確認のどれかを特定してから実装します。

Unit・Component・Integrationの範囲を選ぶ

単一関数の入力と出力が中心ならunit test、画面の操作と利用者に見える状態ならcomponent test、database・API・複数moduleの境界ならintegration testが候補です。どの層でも全部を再現する必要はありません。unit testだけではrouteや認証設定が正しいか分からず、integration testだけでは原因特定やcase網羅が難しいことがあります。既存projectのtest構成と目的に合わせて組み合わせます。

依存をmockに置き換える場合、何をmockして何を実際に動かすかを明記します。requestの失敗までmockしないとtestできないか、単なる実装詳細をmockしているかを確認します。testが内部function名やstateの格納場所に強く依存すると、behaviorを変えていないrefactorでも壊れるため、公開された契約と画面表示を優先します。

Reactの画面testではinteractionを確かめる

React componentでは、初期画面のsnapshotだけで終わらず、入力、クリック、submit、loading、success、empty、errorなどを利用者の操作に近い形で確認します。labelやroleなど利用者が頼る手掛かりを使うと、内部DOM構造の小さな変更に過度に依存しにくくなります。keyboard操作やfocusも必要な範囲で確認します。

React公式のactは、renderやinteractionによる更新をassert前に処理するためのtest helperです。既存のTesting Libraryなどが使われていれば、そのhelperとrunnerに合わせます。新しいtest frameworkを勝手に追加せず、projectのglobal setup、async処理、timer、network mockの規則を確認します。test環境特有のact warningを無視してpass扱いにしないでください。

AI生成testの弱さを検出する

testがpassすることだけでなく、意図した失敗を検出するかを確認します。小さな変更を一時的に加える、例えば境界条件を逆にする、error処理を外す、返り値を変更するなどして、関連testが失敗するか試します。検出しないならassertionやcaseが弱い可能性があります。検証後は一時変更を戻し、test suiteが元の状態でpassすることを確認します。

表は横にスクロールできます

症状	見直す点	修正方向
何でもpassする	assertionが存在するか	具体的な結果を比較
実装変更で大量に壊れる	内部detailへ依存	public behaviorへ寄せる
flaky	時刻、random、network	deterministicな条件に分離
errorを見逃す	failure caseがない	dependency failureを追加
testだけ直して通る	oracleが仕様と不一致	期待値の根拠へ戻る

testを通すために本来の仕様を変更したり、testをskipしたり、retryを増やして不安定さを隠したりしません。原因が環境かproduct behaviorか分からない場合は分けて記録します。

CIと再現性を確認する

ローカルだけでなくCI上で同じtestが実行されるか、実行順に依存しないか、timezone・locale・random・network・shared databaseの影響がないか確認します。test用データは独立して作り、前のcaseの状態を残さないようにします。並列実行で競合するfixtureや同じファイルを使うtestがあれば、隔離方法を検討します。

失敗した場合は、最初のerror、再現条件、ローカルとCIの差、関連commitを記録します。suite全体が一度passしただけで、flaky testが解決したと判断しないでください。retryで通った場合は失敗の根本原因を調べます。

AIものさしの判断

AIへtest codeを任せる前に、人が期待するbehaviorとcaseの優先度を決めます。境界と失敗経路が仕様から明確で、testが実際に問題を検出するなら、生成AIは定型caseの実装を速められます。仕様が未定、testがimplementationをそのままなぞる、CIで再現しない問題がある場合は、testを増やすより契約・環境・期待値の確認を先に行ってください。

Test dataと期待値の独立性を確保する

test用のinputと期待結果は、実装からコピーせず、仕様や別の計算から用意します。複雑な日付計算なら、小さな既知例を手計算し、timezone、月末、うるう年を分けます。権限filterなら、通常利用者と管理者で同じfixtureを使い、見えてよい行を個別に定義します。大量のfixtureをそのまま複製するより、テストの意図を説明できる最小データを作ります。

機密データや本番データをtestへ持ち込まず、必要なら架空の値で形式を再現します。random値を使う場合はseedを固定するか、失敗時に同じcaseを再実行できる情報を記録します。fixture作成そのものに外部サービスや現在時刻が必要なら、依存と変化する条件を明示します。

Testの保守コストを見直す

test数やcoverage率を増やすだけでは、重要なbehaviorが守られるとは限りません。変更のrisk、利用頻度、失敗時の影響から、unit・component・integrationのどこで契約を守るかを決めます。同じ条件を多数のtestで重複確認しているなら、どの層で代表させるか整理します。一方、重要な外部境界や権限条件は、testが一つもない状態を放置しません。

テスト名から前提と期待が読めるようにし、失敗時のmessageに入力やcase識別子を含めます。testを変更する時も、なぜ期待値を変えたかを仕様変更と分けて記録します。コードの内部構造だけが変わった場合は、behaviorに影響しないtest修正かを確認し、不要な期待値変更を避けます。

テスト計画には、未実施のcase、環境上の制約、残るriskを記載します。CIでpassした結果も、どのcommitとdependencyで実行したか分かるように保存します。

仕様にない期待値を、テストの都合だけで正解として固定しないことも重要です。

失敗したtestを直すときは、bug修正・fixture修正・仕様変更のどれかを区別し、関連caseを追加して同じ回帰を防ぎます。test runnerやReactのAPIはversionによって異なるため、projectの実装と現行公式Docsを併せて確認してください。