TDD実践ガイド 2026

Red-Green-Refactorサイクルの思考プロセスから実務での定着まで、SaaS課金管理を題材に追体験する。

目次

プロローグ ── 「テストを先に書けない」を終わりにする ---
TDDとは何か ── Red-Green-Refactorは「テスト手法」ではなく「思考法」 TDDの説明で最も多い誤解は、「テストを先に書くこと」がTDDだと思われていることだ。テストを先に書くのは TDD の結果であって本質ではない。本章では、TDD が本当に何をしているのかを解き明かし、次章以降の実践に必要な思考の型を身につける。
最初のRed-Green-Refactor ── Moneyクラスをテストで駆動する理論は前章で終わった。ここからは手を動かす。
テストリストの技法 ── 「次に何をテストするか」の判断軸前章で最初の Red-Green-Refactor を回した。6サイクルで Money クラスが育った。だが、正直に言おう。前章のテストの順序は筆者が事前に設計した順序だった。
状態を持つオブジェクトのTDD ── Subscriptionの状態遷移を駆動する前章までの Money は状態を持たなかった。一度作ったら変わらない。テストしやすい理想的な型だ。
リファクタリング ── Greenの先にある「設計の発見」 Red-Green-Refactor の3フェーズのうち、最も軽視されているのが Refactor だ。
外部依存を断ち切る ── テストダブルと永続化の境界ここまでの Money と Subscription は、外部依存がなかった。メモリ上で完結するオブジェクトだ。しかし、実際のアプリケーションではデータベースに保存し、取得する必要がある。
副作用をイベントに切り出す ── 通知とテストの独立性 Subscription がキャンセルされたら、メールを送りたい。支払いが失敗したら、Slack に通知したい。プランが変更されたら、課金額を再計算したい。
アンチパターン・カタログ ── TDD実践で踏む地雷を分類するここまでの章で「TDD の正しいやり方」を見てきた。本章では逆に、「TDD の間違ったやり方」を体系的に分類する。
TDDの限界と「使わない判断」── 適用すべき場所、してはいけない場所 TDD は万能ではない。
AI時代のTDD ── Kent BeckのAugmented Codingと2026年の実践 2026年、AIがコードを書くのは当たり前になった。GitHub Copilot、Claude Code、Cursor──これらのツールは、自然言語で指示するだけでプロダクションレベルのコードを生成する。
エピローグ ── 「テストを先に書ける」状態から始まる世界 12章をかけて、TDDの思考法から実践、アンチパターン、限界、AI時代の活用までを歩いてきた。