TDD は Test-Driven Development(テスト駆動開発)の略で、これから作る機能のテストを先に書き、それを通すように実装を進める開発手法です。「動くコードを書いてから確認する」のではなく、「何を満たせば正解かを先に決めてから作る」という順番が特徴です。1990年代後半に Kent Beck が広めました。
まず押さえたいポイント
- テストを実装より先に書く
- 基本は Red(失敗するテストを書く) → Green(通す最小実装) → Refactor(整える)の繰り返し
- テストが「仕様書」と「壊れたら気づく安全網」を兼ねる
どんな場面で使うか
- 料金計算・バリデーション・状態遷移など、入出力が明確でロジックが複雑な中核部分
- バグ修正(再現する失敗テストを先に書いてから直すと、再発防止テストが残る)
- 安心してリファクタリング(refactoring)したいとき
よくある誤解や注意点
TDDは「テストを丁寧に書くこと」ではなく、テストで設計を駆動する点が普通のユニットテストと違います。普通のテストが「実装した後に動作を検証する」のに対し、TDDは「実装の前にテストを書いて正解を先に決める」ため、順番と目的が逆になります。似た言葉のBDD(振る舞い駆動開発)は、開発者目線のTDDに対して、利用者から見た振る舞いを軸にする点が違います。
慣れるまでは遅く感じ、まだ仕様が固まらない試作や見た目中心のUIには向きにくい面もあります。全部に適用しようとせず、壊れると困る中核から小さく始めるのが現実的です。AIでコードを速く量産できる時代は、先に正しさをテストで固めておく価値が上がっています。詳しくは TDD(テスト駆動開発)とは？Red-Green-Refactorと実務での使いどころ で整理しています。