最小の再現テストを書く
テスト一式ではなく、最小の入力で安定して再現する
あなたは境界条件の切り分けが得意なエンジニアです。次のバグに対して、最小の再現テストを一つ書いてください：1）再現に必要な入力と状態だけを残し、それ以外は削る；2）「例外が出ないこと」ではなく、期待値と実際値を具体的に検証する；3）修正前は失敗し、修正後は通ることを明記する；4）安定して再現できない場合は、足りない環境条件を挙げ、推測で埋めない。既存のテストフレームワークを使い、1 ファイルで完結させてください。 ［バグの説明／関連コード／実行環境］
使い方
最小のケースは回帰テストとして残すべきものです。動かないテストや、たまにしか通らないテストは、書かないほうがましです。
向いている場面
- 検索欄を空のままにすると結果ページが落ちる、と顧客から報告がありました。コードに触る前に、この挙動をテストで固定したいときです。
- ページングの off-by-one を直しています。現在の実装で必ず失敗するテストが必要です。
向いていない場面
- 決済モジュール全体の回帰テストが必要な場合です。このプロンプトが作るのは 1 ケースだけで、テスト一式ではありません。
- 原因が分からず、再現もできない段階では、まず計測とログを足します。テストはその後です。
例
入力
function parseRange(s) {
const [from, to] = s.split('-').map(Number);
return { from, to };
}
// parseRange('10') は { from: 10, to: NaN } を返す。期待する to は 10得られるもの
`parseRange('10')` だけを残し、`{ from: 10, to: 10 }` を検証してください（UI とネットワーク層は外します）。まず現在のコードで実行し、失敗出力（`to: NaN`）を貼って、このテストがバグを実際に捕まえることを示します。単一値は不正という仕様なら、テスト名を変えて例外を検証し、二つの意味を曖昧に残さないでください。よくある誤用
- 決済フロー全体を「最小ケース」にすることです。失敗したとき、対象のバグか環境の不安定さかが分かりません。
- 「例外が出ないこと」だけを検証することです。null を返す実装でも通り、バグは固定されません。
こう変えると効く
- 同じケースを三つの境界値（空文字、0、負数）でパラメータ化すると、ファイルを増やさずに周辺も押さえられます。
- 「修正前に必ず失敗」を「現在の失敗出力を貼る」に変えると、約束ではなく証拠が手に入ります。