tdd

TDD によるバグ修正

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

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

ワークフロー

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

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

回帰確認の手順を黙って省略しないでください。修正前に、失敗するテストが不可能である、またはコストに見合わない理由を明確に説明し、利用可能な最も近い実行可能な回帰チェックを選んでください。例として、対象を絞ったスクリプト、手動で再現するコマンド、ブラウザー自動化、スナップショット比較、ログのアサーション、または焦点を絞った統合チェックがあります。

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

ガードレール

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

最終回答

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

• 修正前に失敗したテストまたは実行可能なチェックと、その失敗内容を示します。
• 修正後に成功したテスト実行と、実施した関連範囲の検証を示します。
• 修正前の失敗を確認できなかった場合は、その理由と、代わりに使用した最も近い回帰チェックを説明します。