Write the Tests First（最初にテストを書く）

1. 原則

テストコードは実装対象となるコードを書く前に作成する

• ユニットテストを、実装対象となるコードを書く前に作成する
• 「レッド・グリーン・リファクタリング」のサイクルを構成する
  • レッド: 失敗するテストを最初に書く
  • グリーン: そのテストを通すための最小限のコードを実装する
  • リファクタリング: コードの品質を改善する
• 開発者がコードの振る舞いを事前に明確に定義し、それに従って実装を進めることを強制する

2. 根拠

設計の改善

• テストを先に書くことで、テストしやすい（＝疎結合で単一責任の）設計を自然と志向できる
• テストが書きにくい場合、それは通常、コードの設計に問題があることの兆候

バグの早期発見

• 実装と同時にテストを行うため、バグを早い段階で発見し、修正コストを大幅に削減できる

仕様の明確化

• テストケースは、コードが満たすべき振る舞いの仕様書として機能する
• 開発者は「何を作るべきか」を具体的に理解してから実装に着手できるようになる

リファクタリングの安全網

• テストスイートが堅牢なセーフティネットとなり、安心してコードの改善（リファクタリング）を行えるようになる

3. 指針

最小単位から始める

• 最初に、テスト対象の機能の最も単純なケースに対するテストを書く

失敗するテストを書く

• 実装コードが存在しないため、テストが必ず失敗することを確認する

最小限の実装

• テストを成功させるためだけの最小限のコードを実装する
• 余計な機能や将来の拡張は考えない

リファクタリング

• テストが通った後、コードの重複排除や可読性向上など、品質改善を行う
• この際、すべてのテストが引き続き成功することを確認しながら進める

このサイクルを繰り返す

• 新しい機能や振る舞いを追加するたびに、この「レッド→グリーン→リファクタリング」のサイクルを繰り返す

4. 注意事項

テストの対象

• ユーザーインターフェースや外部サービスとの統合部分など、テストが困難な領域にはこの原則を直接適用しにくい場合がある

過剰なテスト

• すべての些細なコード変更に対応するテストを書くことは、メンテナンスコストを増大させる可能性がある
• テストは、コードの振る舞いを検証するものであり、内部実装をテストするべきではない

学習曲線

• この原則は、特に初心者の開発者にとって習得に時間がかかる場合がある
• 習慣化するには、継続的な実践が必要となる

テストの粒度

• ユニットテストが適切に小さい粒度で書かれていることを意識する
• 大きな機能に対するテストではなく、個々のメソッドや関数が単一の目的を満たしているかを確認する