tdd

tdd

エージェントは、長い仕様書よりも短いフィードバックループがあるほうが、よりよくコードを書けます。失敗するテストは、最も短いループです。目標を明示し、その目標を達成できたかどうかを確認できます。

ループ

1. Red。 次の動作の一部分を示す、失敗するテストを1つ書きます。実行して、意図した理由で失敗することを確認します。コードを書く前に通ってしまうテストでは、何も検証できません。アサーションで失敗するのではなくエラーになる場合は、まずテストのセットアップを修正します。
2. Green。 テストを通すために必要な最小限のコードを書きます。一般的な解決策でも抽象化でもなく、最小限の変更です。テストを実行します。成功です。
3. リファクタリング。 テストを安全網として、重複をなくし、名前を付け、シンプルに整理します。編集するたびに再実行します。動作は変えず、構造だけを変更します。
4. 次の一部分に進み、繰り返します。小さな単位で進めます。フィードバックの速度が進行速度の上限です。1つのテストで確認しきれないほど大きな手順には決して取り組まないでください。

書く価値のあるテストとは

• 実装ではなく動作をテストします。 どのプライベートメソッドが呼び出されたかではなく、観測できる結果を検証します。リファクタリングのたびに壊れるテストは負担になります。
• 失敗の理由は1つです。 各テストで1つの動作を固定します。失敗したとき、テスト本体を読まなくても何が壊れたのかが分かるようにします。
• 実際の境界を使い、モックは最小限にします。 内部の協調相手ではなく、システム境界（ネットワーク、時計、ファイルシステム）をモックします。テスト対象そのものをモックするテストでは、何も検証できません。
• 同語反復を避けます。 実装をそのまま言い換えたテスト（xを設定したあとにexpect(x).toBe(x)とするなど）では何も検証できません。その動作が生み出すべき値を検証します。

使う場面

動作を仕様化でき、テストで固定できる場合にTDDを使います。ビジネスロジック、パーサー、ステートマシン、バグ修正（まず失敗するケースを書き、その後で修正する）が該当します。純粋な探索、一時的な試作、テストで人間が目視確認できること以上を検証できないレイアウトのみのUIでは、使わないでください。

出力の条件

最終的にテストが通ったことだけでなく、RedからGreenへの各移行を示します。テストを書くのが難しい場合は、その難しさから設計について何が分かるのかを説明してください。テストできないコードは、たいてい適切な境界で分割されていないコードです。これは障害ではなく、発見事項です。