ds-tdd

ds-tdd

本番コードに手を加える前に、バグを再現できる形にして、修正を主張ではなく実証します。

手順

1. バグを明確にします。期待される動作、実際の動作、該当するコードパス、最小の再現方法を特定します。
2. そのコードパスに最も近い既存のテストスタイルを見つけて使用します。このためだけに新しいテストハーネスを作らないでください。
3. バグを検出できたはずの最小限のテストを書きます。現在の実装ではなく、意図した動作を検証します。
4. テストを実行して、出力を示します。テストは失敗しなければなりません。また、タイプミスやインポート漏れではなく、バグが原因で失敗する必要があります。そうでなければ、まずテストを修正します。
5. 近接する既存の契約を壊さず、意図した動作を実現する最小限の本番コード変更を行います。
6. 新しいテストと周辺のテストスイートを実行して、出力を示します。
7. クリーンなテストが現実的でない場合（セットアップが重い、モックが壊れやすい、本番環境でしか存在しない状態など）は、代わりに実行可能な最も近い確認方法（スクリプト、再現コマンド、ログの確認など）を使います。テストを省略した理由を述べてください。

次の場合に停止します

• 新しいテストが修正前に失敗し、修正後に成功したことを、どちらも出力とともに示せて、周辺のテストスイートも成功した場合。
• または、修正を3回試してもテストが失敗する場合。その時点で停止し、分かったことを報告して /ds-unstick を実行します。

ルール

• 誤った実装に合わせてテストを編集しないでください。
• 明確な理由を述べずに、既存のアサーションを弱めないでください。
• テストは悪いテストより優れているわけではありません。モックばかりを検証するテスト、タイミングに依存するテスト、すぐに削除されるようなテストは避けてください。