TDD は『テストを先に書く流派』ではなく『設計を学ぶ実践』
TDD は Kent Beck らによって体系化された開発スタイルで、テストを先に書くことで設計品質と保守性が向上します。本記事では編集部の視点で、実務で続けるためのコツを公開情報をもとに整理します。Playwright 実践 もご参考に。
Red-Green-Refactor の基本
(1) Red：失敗するテストを書く。(2) Green：最小実装で通す。(3) Refactor：重複を取り、設計を改善。(4) サイクル時間：数分〜30分が目安。(5) 1機能 = 多サイクル：小刻みに前進。
テストの粒度設計
(1) テストピラミッド：単体7 / 結合2 / E2E1 の比率。(2) 単体テスト：純粋関数中心、依存はモック。(3) 結合テスト：DB/外部APIを含む。(4) E2E テスト：クリティカルパスのみ。(5) テストの命名：振る舞いを文章化。
設計改善の効果
(1) 結合度の低下：依存を注入したくなる。(2) 純粋関数化：副作用をテスト境界外に追い出す。(3) 命名の改善：テスト名が仕様書になる。(4) YAGNI 思想：必要な機能だけ実装。(5) リファクタの安心感：常に緑のテストが盾。
続かない時の対処
(1) テストが書きにくい時は設計の問題：依存を疑う。(2) 仕様未定義の機能：プロトタイプ→TDDの順で。(3) UI/CSS は TDD 苦手領域：視覚回帰テストで補完。(4) 外部API依存：契約テスト・コントラクトテストを活用。(5) レガシーコード：先に Characterization Test。AIコーディングエージェント比較 でAI活用も。
AI 時代の TDD
(1) テストをAIに先に書かせる：仕様の明確化に有効。(2) 実装をAIに任せる：テストが通れば OK。(3) リファクタは人間が判断：可読性は人の感性。(4) 境界条件をAIに列挙させる：人が見落とすケースを発見。(5) テスト命名もAI支援：日本語/英語切替も容易。
失敗しがちなパターン
(1) テストを書かずに進める：戻れない設計に。(2) 過大なテスト：1テストで複数振る舞いを検証。(3) 実装に依存したテスト：リファクタで全壊。(4) カバレッジ至上主義：100%を目指して意味のないテスト量産。(5) 遅すぎるテスト：CI で10分以上。対策は、(1)Red から始める習慣、(2)1テスト1観点、(3)振る舞い検証、(4)80%目安、(5)並列実行+遅いテスト分離、です。