TL;DR
失敗する自動テストを先に書き、それを通す最小限のコードを書き、コードとテストをリファクタリングする。このサイクルを繰り返してソフトウェアを作る開発手法。Kent Beck が考案した、あるいは「再発見」したとされる。
なぜ必要か
テスト駆動開発（書籍） によると、TDD は単なるテストの自動化ではない。単体テストとリファクタリングを両輪とした小さいサイクルを回して不確実性を制御し、設計を進化させ続ける手法である。
Wikipedia によると、TDD は開発中に素早いフィードバックをくれるので、リグレッションを早く見つけられ、リファクタリングもしやすくなる。テストを先に書くと、実装の前に望ましいインターフェースを考えることになるので、小さく疎結合な単位に分けやすくなる。
仕組み
1 つのサイクルは Red、Green、Refactor の 3 段階からなる。
- Red: 期待する振る舞いを 1 つテストに書き、想定どおりの理由で失敗することを確かめる
- Green: 見栄えが悪くてもよいので、新しいテストを通す最も単純なコードを書く
- Refactor: すべてのテストが通る状態を保ったまま、コードとテストを読みやすく、保守しやすく整える
注意点
Wikipedia によると、TDD は他の種類のテストの代わりにはならない。TDD で書いたテストは、本番のコードと同じ誤解を抱えていることがある。範囲が狭いテストや実装の詳細に依存したテストが大量に通っていても、安心してよいとは限らない。TDD の効果を調べた実証研究の結果もまちまちである。