tdd

TDD によるバグ修正

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

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

ワークフロー

1. バグを理解する。 意図された動作、現在の動作、影響を受ける経路、そして最小限の観測可能な再現方法を特定します。
2. 最も範囲の狭い実行可能なチェックを選ぶ。 そのコードパスですでに使われている、最も近いユニットテスト、コンポーネントテスト、統合テスト、または回帰テストを優先します。現実的なテスト方法が明らかでない場合は、ワークフローを満たすためだけにゼロから作成しないでください。
3. 失敗するテストを先に書く。 バグを検出できたはずの、最小限で焦点を絞ったテストを追加します。テストには意図された動作を記述し、現在の実装をなぞらないでください。
4. 修正前に新しいテストを実行する。 意図した理由で失敗することを確認します。成功する場合や、無関係な理由で失敗する場合は、実装を編集する前にテストまたは再現方法を修正します。
5. バグを修正する。 周辺の契約を維持しながら、意図された動作を満たす最小限の本番コード変更を行います。
6. 回帰テストを再実行する。 テストが成功することを確認します。

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

代わりに、実行可能な回帰チェックの中から最も適したものを使います。たとえば、対象を絞ったスクリプト、手動再現コマンド、ブラウザー自動化、スナップショット比較、ログ検証、または焦点を絞った統合チェックです。

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

ガードレール

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

最終回答

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

• 修正前に失敗したテストまたは実行可能なチェックの名前と、その失敗内容を示します。
• 修正後に成功したテスト実行と、近接する検証を示します。
• 修正前の失敗を実証できなかった場合は、その理由を述べ、代わりに使用した最も適切な回帰チェックを説明します。