tdd

TDD

1. 依頼内容、関連資料、および該当するコードを確認します。未確定の判断によって動作、インターフェース、またはチェック内容が変わる場合に限り、テストを書く前に質問します。
2. Red：動作を証明する、またはバグを再現する最小限の失敗するテストを書きます。テストを実行し、想定した理由で失敗することを確認します。
3. Green：テストに合格する最小限の実装を書きます。タスクで必要とされない限り、既存のインターフェースやユーザーから見える動作を変更しません。重要な失敗経路についてはテストを追加します。
4. Refine：テストに合格したまま、コードとテストを簡潔にします。まず対象を絞ったチェックを実行し、その後、より広範なチェックを行います。
5. 事前には失敗し、実施後には合格したテストと、最終チェックの結果を報告します。

ルール

• 対象の動作について失敗するテストを書く前に、実装コードを書いてはいけません。
• リスクの低い前提は明示し、作業を続けます。
• テストでは実装の詳細ではなく、動作を記述します。
• 実用的な場合は、モックより実際の境界を優先します。
• ドキュメント、書式設定、または動作に関わらない足場づくりでは、TDDを省略します。