tdd

TDD によるバグ修正

明確で手軽なテスト方法があるバグを修正する場合は、本番コードを変更する前に、壊れた動作を実行可能な形にします。目的は、修正前には失敗し、修正後には成功する、焦点を絞った回帰テストです。

現実的でない場合は、無理にテストを作成しないでください。利用可能なテストに大規模なハーネスの準備、壊れやすいモック、時間のかかるエンドツーエンドのインフラ、本番環境でしか得られない状態、曖昧な再現手順、または無関係なフィクスチャの大幅な変更が必要になる場合は、新しいテストの追加を見送り、代わりに最も有用な検証方法を使用してください。

ワークフロー

1. バグを理解します。 期待される動作、現在の動作、影響を受ける経路、および最小限の観測可能な再現方法を特定します。
2. 最も範囲の狭い実行可能なチェックを選びます。 そのコードパスですでに使用されている、最も近いユニットテスト、コンポーネントテスト、統合テスト、または回帰テストを優先します。現実的なテスト方法がすぐに見つからない場合は、ワークフローを満たすためだけにゼロから作成しないでください。
3. 最初に失敗するテストを書きます。 バグを検出できたはずの、最小限で焦点を絞ったテストを追加します。テストでは現在の実装を模倣するのではなく、期待される動作を表現してください。
4. 修正前に新しいテストを実行します。 期待した理由で失敗することを確認します。アサーションの行ではなく、失敗の内容を引用してください。例外、リテラル値と照合した空の結果、予測された不一致はいずれも赤で表示されますが、バグを測定していることを証明するのは最後のケースだけです。テストが成功した場合、または無関係な理由で失敗した場合は、実装を編集する前にテストまたは再現方法を修正してください。
5. バグを修正します。 周辺の契約を維持しながら、期待される動作を満たす最小限の本番コード変更を行います。
6. 回帰テストを再実行します。 テストが成功することを確認します。

失敗するテストが現実的でない場合

代わりに、最も近い実行可能な回帰チェックを使用します。対象を絞ったスクリプト、手動の再現コマンド、ブラウザー自動化、スナップショット比較、ログのアサーション、または焦点を絞った統合チェックなどが該当します。

不適切なテストを追加するより、テストを追加しない方を優先してください。不適切なテストとは、主にモックをテストするもの、現在の実装の詳細を固定するもの、タイミングや無関係なグローバル状態に依存するもの、小さな修正に高価なインフラを必要とするもの、または修正を証明した直後に削除されるものです。

ガードレール

• 誤った実装に合わせるためだけにテストを変更しないでください。
• 期待される動作が実際に変更され、その理由が明確でない限り、既存のアサーションを弱めないでください。
• 回帰テストはバグに焦点を絞ってください。フィクスチャの大幅な変更や、無関係なカバレッジの拡大は避けてください。
• バグが不安定に発生する場合は、可能な限りテストを決定的にし、固定するシグナルを文書化してください。
• バグによってより広範な種類の失敗が明らかになった場合は、まず焦点を絞った回帰経路を追加し、その後で関連する追加カバレッジを検討してください。

最終回答

結果だけでなく、根拠を報告してください。

• 失敗した修正前のテストまたは実行可能なチェックの名前と、そこで出力された失敗内容を差分に絞って引用します。
• 成功した修正後のテスト実行と、実施した関連検証を記載します。
• 修正前の失敗を実証できなかった場合は、その理由を述べ、代わりに使用した最も近い回帰チェックを説明します。