tdd

TDD

事前に合意した境界で、小さなステップでレッドからグリーンへ進めます。ローンチ実行時は、境界のリストが C2 の承認済み出力です。ローンチ以外では、最初のテストを作成する前にユーザーと境界について合意します。誰も承認していない境界にはテストを作成しません。

サイクル

テストを1つ → 実装を1つ → 繰り返します。

1. 次の境界でテストを作成します。実行し、想定した理由で失敗することを確認します。失敗しないテストはテストではありません。
2. テストをグリーンにする最小限の変更を実装します。
3. 繰り返します。各テストはトレーサーバレットです。振る舞いを通る、狭くても完全な経路であり、単独のレイヤーを仕上げるものではありません。

ルール

• 期待値は独立した信頼できる情報源（仕様の記述、具体的な例、文書化された出力など）から取得します。テスト対象の実装から取得してはいけません。コードがたまたま行うことをアサートするテストは検証ではなく、単なる反映です。
• 置き換えは、境界に対して宣言されたクラスのみに限ります。クラスは、インプロセス、ローカルで置き換え可能、所有するリモートポート、または真の外部です。C2 は各境界のクラスを記録します。テスト対象の境界内部では、置き換えを行いません。
• リファクタリングはこのサイクルには含まれません。レビュー段階で行い、修復担当者が担います。レッドからグリーンへ進む途中でリファクタリングしてはいけません。
• バグ修正は、そのバグを再現する失敗テストから始めます。理論より再現を優先する。これがデバッガーの原則です。
• 境界を提案するときは、それが何を検出し、何を見逃すかを1行で述べます。評価できない境界の選択は、決定ではなく推測です。

適合する境界がない場合

承認済みの境界で振る舞いをテストできない場合は、停止してその旨を伝えます。存在しない境界を所見として報告します（architecture-survey と refit に引き継がれます）。境界を捏造したり、内部を通じてテストしたりしてはいけません。

出力

• 使用した境界リスト。各境界のクラスと、検出するもの／見逃すものを記した行を含めます
• レッド／グリーンの証拠。失敗した実行と成功した実行
• 境界が存在しない場合の所見