先に要点
- TDD(テスト駆動開発)は、実装より先にテストを書く開発手法です。「動くコードを書いてから確認」ではなく、「何を満たすべきか(テスト)を先に決めてから実装する」という順番の違いが本質です。
- 基本は Red → Green → Refactor の短いサイクル。まず失敗するテストを書き(Red)、それを通す最小限のコードを書き(Green)、動くまま整える(Refactor)を小刻みに繰り返します。
- 普通のユニットテストとの違いは 順番と目的。あとから検証するのがテスト、先に書いて設計を駆動するのがTDDです。テストが「仕様書」と「安全網」を兼ねます。
- メリットは 手戻りの早期発見・小さく安全に進める・リファクタしやすい。一方で 慣れるまで遅い・UIや探索的な実装には向きにくいという限界もあります。
- AIでコードを速く量産できる時代ほど、「そのコードが本当に正しいか」を先に決めるTDDの価値が見直されています。全部に使うより、ロジックが複雑な中核から始めるのが現実的です。
テストって、コードを書いた後に書くものじゃないの？ ── TDDを初めて聞くと、たいていここでつまずきます。TDD(Test-Driven Development)は、その常識をひっくり返して テストを先に書いてから実装する手法です。順番を変えるだけに見えて、設計の進め方や安心感が大きく変わります。
この記事では、TDDを 基本の考え方 → Red-Green-Refactorサイクル → 普通のテストとの違い → メリットと限界 → AI時代での位置づけ → 実務での始め方の順で整理します。考え方は Kent Beck が提唱し、Martin Fowler らの解説が定番の一次情報です。
TDDとは(テストを先に書く)
TDD(テスト駆動開発)は、これから作る機能が満たすべき条件を「テスト」として先に書き、そのテストを通すように実装を進める開発手法です。1990年代後半に Kent Beck が エクストリームプログラミングの一部として広め、著書『Test-Driven Development: By Example』(2002)でサイクルが定式化されました。
ポイントは 「テスト」を、あとで動作確認するためだけの道具にしないことです。TDDではテストが 「これから作るものの仕様」であり、同時に 「壊れたら教えてくれる安全網」にもなります。先に「何ができれば正解か」を書くので、実装が迷子になりにくいのが特徴です。
Red-Green-Refactor サイクル
TDDの中心は、Red → Green → Refactor という短いサイクルを小刻みに回すことです。1周が数分で終わるくらい小さく刻むのがコツです。
この 「赤(失敗)→緑(成功)→整える」を繰り返すのがTDDの背骨です。Refactorで安心して整理できるのは、いつでもテストで動作を確認できる状態を保っているからです。
普通のテストとの違い(順番と目的)
「テストを書く」という点だけ見ると普通のテストと同じですが、順番と目的が違います。
| 観点 | 普通のユニットテスト | TDD |
|---|---|---|
| 書く順番 | 実装した後に書く | 実装の前に書く |
| 主な目的 | できたコードの動作検証 | 設計を駆動する＋検証も兼ねる |
| テストの役割 | 安全網 | 仕様書 ＋ 安全網 |
| 進め方 | まとめて作ってから確認 | 小さく作りながら常に確認 |
つまり、あとから検証するのがテスト、先に書いて設計を引っ張るのがTDDです。テストの書き方(ユニットテストの技術)そのものは共通なので、まずVitestのようなテストツールやテストカバレッジの基礎を押さえておくと、TDDにも入りやすくなります。
TDDとBDDの違い
TDDとよく並べて語られるのが BDD(振る舞い駆動開発)です。混同しやすいので切り分けます。
ざっくり言うと、TDDは「コードが正しく動くか」を開発者目線で、BDDは「利用者にとって期待通りか」を要求目線で駆動します。対立するものではなく、両方を組み合わせるチームもあります。
メリットと限界(向く場面・向かない場面)
TDDは万能ではありません。効く場面と、無理しなくてよい場面を分けて考えるのが実務的です。
メリット
手戻りを早く見つけられる、小さく安全に進められる、リファクタしやすい、テストが仕様書代わりになり後任が読める。
デメリット・限界
慣れるまで遅く感じる、テスト自体の保守コスト、UIや探索的な試作には向きにくい、テストの書き方が悪いと逆に足かせになる。
向く場面
料金計算、バリデーション、状態遷移、入出力が明確でロジックが複雑な中核部分。「仕様を1つずつ固めたい」ところ。
向きにくい場面
まだ仕様が固まらない試作、見た目中心のUI、外部依存が大きく何が正解か先に書きにくい部分。
AIでコードを量産できる時代のTDD
2026年時点で、TDDは あらためて見直されています。理由は、AIでコードを速く大量に書けるようになったことです。「まず書かせて、後で確かめる」がやりやすくなった分、「そのコードが本当に満たすべき条件は何か」を先に決めておく価値が上がっています。
テストを先に書いておけば、AIに実装させたコードが正しいかを その場で機械的に判定できます。逆に、テストが無いままAIの出力を積み上げると、「動いてはいるが、何を保証しているのか誰も分からない」コードになりがちです。全部をTDDにする必要はありませんが、ロジックが複雑で壊れると困る中核だけでも、テストを先に固めるのは、AI時代でむしろ相性がよい進め方です。
実務での始め方
いきなり全部をTDDにしようとすると挫折しやすいので、小さく始めます。
- 入出力が明確な関数から ── 料金計算、日付処理、バリデーションなど「正解を1つ書ける」ところを選ぶ。
- 1つの小さなテストから ── 最初のRedを1個書いて、Greenにして、Refactorする。この1周を体で覚える。
- バグ修正で使う ── バグを再現する失敗テストを先に書き(Red)、直して通す(Green)。再発防止のテストがそのまま残る。
- テストが書きにくい設計は見直す ── 「テストしにくい」は、依存が絡まりすぎのサインでもある。
まずはバグ修正時の「再現テストを先に書く」からだと、TDDの手触りをつかみやすいです。
TDDに関するよくある質問
TDDと普通のテストの違いは何ですか？
順番と目的です。普通のテストは 実装した後に動作を検証します。TDDは 実装の前にテストを書き、それを通すように実装を進めます。TDDではテストが「これから作るものの仕様」と「壊れたら気づける安全網」を兼ねます。
Red-Green-Refactorとは何ですか？
TDDの基本サイクルです。Red=まず失敗するテストを書く、Green=それを通す最小限の実装を書く、Refactor=テストが通るまま整える、を小刻みに繰り返します。1周を数分で回せるくらい小さく刻むのがコツです。
TDDにすると開発は遅くなりませんか？
慣れるまでは遅く感じます。ただし、手戻りやデバッグの時間が減るため、複雑なロジックでは全体として速くなることも多いです。UIや試作など向かない場面まで無理に適用しないのが現実的です。
TDDとBDDはどちらを使うべきですか？
対立しません。TDDは開発者目線でコードの正しさを、BDDは利用者目線で振る舞いを駆動します。ロジックの正しさを固めたいならTDD、要求と実装のズレをなくしたいならBDD、と目的で選び、併用もできます。
AIでコードを書く時代にTDDは意味がありますか？
むしろ相性がよいです。テストを先に書いておけば、AIに書かせたコードが正しいかをその場で機械的に判定できます。テスト無しでAIの出力を積むと「何を保証しているか分からない」コードになりがちなので、中核だけでもテストを先に固める価値が上がっています。
何から始めればいいですか？
入出力が明確な関数か、バグ修正から始めるのがおすすめです。特にバグ修正は、再現する失敗テストを先に書いて(Red)から直す(Green)と、再発防止テストが自然に残り、TDDの手触りをつかみやすいです。
まとめ
TDD(テスト駆動開発)は、実装より先にテストを書き、Red(失敗)→Green(成功)→Refactor(整える)の短いサイクルを小刻みに回す開発手法です。普通のテストとの違いは順番と目的で、テストが仕様書と安全網を兼ねる点が肝です。慣れるまでは遅く感じ、UIや試作には向きにくい一方、ロジックが複雑な中核では手戻りを減らし、安心してリファクタできる強みがあります。AIでコードを量産できる時代ほど「先に正しさを決める」価値は上がっているので、まずは入出力が明確な関数やバグ修正から小さく試すのがおすすめです。
参考リンク
- Martin Fowler: Test Driven Development(bliki)
- Wikipedia: Test-driven development
- 関連記事: Vitestとは / テストカバレッジとは / Playwrightとは