AI テスト生成ワークフロー：推測ではなく振る舞いから回帰保護を作る

呼び出し元が観測できる入力、状態遷移、出力、副作用から始め、正常値、境界値、不正入力、必要なエラー挙動を明記します。期待値に合意がなければ、アサーションを生成する前に契約を確定します。

編集前に近隣テストを見つけ、fixture、命名、ヘルパー、配置規則を説明させます。既存のテスト構造もリポジトリ契約です。

安定した関数境界には単体テスト、コンポーネント契約には結合テスト、下位層で確認できないユーザーフローだけに E2E テストを使います。全階層を既定で追加しても、新しい信号なしに保守コストが増える場合があります。

振る舞いごとに少数を生成し、名前とアサーションを確認してから増やします。各テストには明確な失敗理由が必要で、スナップショットは出力自体がレビュー済み契約の場合に限ります。

追加する fixture と mock を説明させます。隠れた共通 setup は、確認すべき経路を迂回させることがあります。

不具合修正では、未修正版で新しいテストを実行するか、対象修正を一時的に戻して、アサーションが古い挙動を検出することを確認します。その後、実装を復元して成功する結果も記録します。

変更前後の両方で成功するテストは有用な場合がありますが、今回の回帰を保護する証拠にはなりません。

対象テストを繰り返し単独実行し、関連テストや標準スイートとも実行します。順序、時刻、乱数、一時ファイル、ネットワーク、後始末を確認し、失敗が対象の振る舞いを明確に示すかレビューします。

テスト意図を読みやすくし、重複 setup を整理し、実装コードと同じレビューで所有者を決めます。仕様変更時は契約とテストを一緒に見直し、回帰に合わせて期待値を静かに変更させません。