テスト駆動開発
テストくどうかいはつ
テストを先に書き、通す最小実装と改善を短く回す開発手法。設計を駆動するのが本質。
概要
テスト駆動開発（TDD: Test-Driven Development）は、実装コードを書く前にそのコードへのテストを書く開発手法です。「まだ存在しない機能のテストを書いて失敗させる（レッド）→ そのテストを通す最小限の実装を書く（グリーン）→ 動く状態を保ったままコードを整理する（リファクタ）」という数分単位のサイクルを、小刻みに何度も回しながらソフトウェアを育てていきます。
名前から「テストの手法」だと誤解されがちですが、TDD の本質はテスト技法ではなく設計と開発の進め方です。テストを先に書くという行為は、「このコードはどう呼び出されるべきか」「何ができたら完成か」を実装より先に決めることを意味します。テストは開発を駆動するハンドルであり、その副産物として回帰テスト（後の変更で壊れていないかを検知するテスト群）が残る、というのが正確な理解です。
なぜ生まれたか
テストを後から書く従来の順序には、構造的な問題がありました。実装が終わった時点でテストを書くのは消化試合になりがちで、締め切りに追われれば真っ先に削られます。さらに、テストのことを考えずに書かれたコードはしばしば依存が絡み合っていてテストを書くこと自体が困難であり、「テストしにくいから書かない → 安全網がないからリファクタリングできない → 構造が劣化する」という悪循環に陥ります。また「何ができたら完成か」が曖昧なまま実装を進めると、作りすぎ（過剰な汎用化）や作り忘れが起きやすいという問題もありました。
Kent Beck は1990年代末、XP（エクストリーム・プログラミング）の実践の中でこの順序を反転させ、2002年の著書『テスト駆動開発』で手法として定式化しました。テストを先に置けば、完成の定義が実装前に明文化され、テスト可能な構造が最初から強制され、安全網は開発と同時に育ちます。Beck 自身はこれを「プログラミング中の不安を管理する技法」と呼びました。小さく確実な一歩を刻み続けることで、「動くかどうか分からない大きな変更」への恐怖を消すことが狙いです。
詳細
レッド・グリーン・リファクタのサイクル
TDD の基本動作は3つの状態を短く巡回することです。1周は数分、長くても十数分が目安です。
レッドの段階では、次に実現したい振る舞いをテストとして書き、実行して失敗を確認します。失敗の確認は儀式ではなく、「このテストは正しく失敗できる＝実装を検証する力がある」ことの検証です。グリーンの段階では、そのテストを通す最小限のコードを書きます。ここでは仮実装（定数をベタ書きで返すなど）すら許されます。きれいさよりもまず「動く」状態に到達することが優先です。リファクタの段階で、テストが通ったままであることを安全網にして、仮実装の一般化や重複の除去を行います。「動くコードを書く」フェーズと「きれいなコードにする」フェーズを意図的に分離するのが、このサイクルの設計思想です。
テストは設計行為である
TDD がもたらす最大の効用は、テストを書く行為がそのまま設計のフィードバックになることです。テストはコードの最初の利用者です。テストを書こうとして「準備するオブジェクトが多すぎる」「この関数を呼ぶには裏で動くデータベースが必要だ」と感じたら、それは結合が強すぎる・責務が多すぎるという設計の警告です。テストしやすいコードは、依存が外から差し替えられ（依存性注入と相性がよいのはこのためです）、責務が小さく、結合度が低く凝集度が高いコードと自然に重なります。「テストの書きにくさは設計の悪さのセンサーである」— これが「TDD はテスト手法ではなく設計手法」と言われる理由です。
また、テストを先に書くことは「外側から内側へ」考えることを強制します。実装の都合ではなく、呼び出す側にとって自然なインターフェースがどんな形かを先に決めるため、使いやすい API になりやすいのです。
ユニットテストとの関係
TDD で書かれるテストの多くは、関数やクラス単位の小さなユニットテストです。ただし「ユニットテストがある」ことと「TDD をしている」ことは別物です。実装後にテストを書き足しても優れた回帰テスト群は得られますが、設計へのフィードバックというTDD 固有の効用は、先に書くからこそ生まれます。逆に TDD の産物であるテスト群は、CI/CD パイプラインで全変更に対して自動実行されることで、チーム全体の安全網として最大の価値を発揮します。テストが遅いとサイクルの回転が鈍るため、TDD の実践者はテストの実行速度（数秒で全件回ること）に強くこだわります。
向く場面と向かない場面
TDD は万能ではなく、効果が高い場面とそうでない場面があります。向いているのは、入出力の関係が明確に定義できるロジック — 業務ルール、料金計算、パーサ、データ変換など — で、仕様をテストとして一つずつ言語化しながら進む恩恵が最大化されます。バグ修正も好相性で、「バグを再現する失敗テストを書いてから直す」ことで、同じバグの再発を構造的に防げます。
一方、正解が事前に定義しにくい領域では素直に適用できません。UI の見た目やレイアウト、探索的に書き捨てるプロトタイプ、機械学習モデルの出力のような非決定的な結果などです。また、テストの粒度を細かくしすぎて実装の内部構造にテストが密着すると、リファクタリングのたびにテストを書き直す羽目になり、安全網であるはずのテストが変更の足かせに変わります。テストすべきは「外から見た振る舞い」であって実装の詳細ではない、という原則は、TDD を長く続けるうえで最も重要な勘所です。手法を教条的に全面適用するのではなく、フィードバックを早く回すという目的に照らして適用範囲を選ぶことが、アジャイルの文脈で生まれたこの手法自身の精神にかなっています。