振り返り
12章をかけて、TDDの思考法から実践、アンチパターン、限界、AI時代の活用までを歩いてきた。
最後に、この旅で起きたことを振り返ろう。
テストが設計を駆動した軌跡
SaaS課金管理システムを題材に、テストで駆動しながらコードを書いてきた。各章で何が生まれたかを一覧にする。
| 章 | テストが要求したこと | 生まれた設計 |
|---|---|---|
| Ch.3 | 金額が不正な値を受け付けないこと | 自己検証する型（Money） |
| Ch.3 | 同じ金額・同じ通貨なら同一であること | 値による等価性 |
| Ch.3 | 演算が元の値を変えないこと | 不変性 |
| Ch.5 | 状態遷移が不正なパスを通らないこと | ライフサイクルとガード（Subscription） |
| Ch.5 | 識別子で個体を区別すること | 一意な識別子 |
| Ch.7 | ビジネスロジックがDBなしで動くこと | 永続化の抽象化層（Repository インターフェース） |
| Ch.7 | テストが高速に実行できること | InMemory Fake |
| Ch.8 | ビジネスロジックが副作用に依存しないこと | イベントによる副作用の分離 |
| Ch.8 | 各副作用が独立してテストできること | イベントハンドラー |
ある発見
ここで、一つの発見を共有したい。
上の表を別の角度から見てみよう。
テストで駆動して生まれたもの その設計パターンの名前
──────────────────────────────────────────────────────
自己検証 + 値で比較 + 不変の型 → Value Object
識別子 + ライフサイクル + ガード → Entity
永続化の抽象化インターフェース → Repository
起きた事実を記録し、反応を分離 → Domain Eventsテストで駆動してコードを書いていったら、ドメイン駆動設計（DDD）の戦術的パターンと同じ構造に辿り着いた。
これは偶然ではない。
TDD は「正しい振る舞い」をテストで定義し、その振る舞いを満たす最小のコードを書き、リファクタリングで構造を整える。DDD は「ビジネスの本質」をモデルで表現し、その本質を守る型・ガード・境界を設計する。
出発点が違うだけで、辿り着く場所は同じだ。
テストから出発しても、ドメインの本質から出発しても、「信頼できるソフトウェア」を作ろうとすれば、同じ設計パターンに収束する。不変の値は自己検証するべきだし、ライフサイクルを持つ個体はガードで守るべきだし、永続化は抽象化するべきだし、副作用は分離するべきだ。
TDD とDDD は、同じ山を違う登山口から登っているに過ぎない。
姉妹記事への架け橋
本記事には姉妹記事がある。
| 記事 | 焦点 | 本記事との関係 |
|---|---|---|
| 戦術的DDD実践ガイド 2026 | DDDの戦術的パターン | 本記事でテストから「発見」した設計を、DDDの語彙で体系化 |
| EvansとVernonで学ぶDDD | DDDの2大原典の比較 | 本記事の設計パターンの理論的背景 |
| DCB（Dynamic Consistency Boundary） | 集約を超える新概念 | 本記事 Ch.5 の状態遷移ガードの先にある議論 |
同じSaaS課金管理システムを題材に、異なる視点から設計を探求している。TDD記事で「テストが駆動した設計」として体験したものが、DDD記事では「ドメインモデリングの結果として設計されたもの」として説明されている。
両方を読むと、テスト駆動とドメイン駆動が同じ設計原則の表裏であることが立体的に見えてくる。
「テストを先に書ける」状態から始まる世界
本記事のプロローグで、こんな状態を描いた。
・Red-Green-Refactor のサイクルは知っている。概念は理解した。
・でも実装しようとすると、「テストを先に書く」の一歩目が出ない。12章を読み終えた今、この状態は解消されているだろうか。
テストを先に書くのが「自然」になるまでには、もう少し時間がかかるかもしれない。だが、本記事で体験した以下のことは、すぐに使える。
今日から使えること：
1. テストリスト（Ch.4）を書いてから実装を始める
2. 1サイクル5〜10分のリズムを守る（Ch.2）
3. Green の後に30秒立ち止まってリファクタリングを考える（Ch.6）
4. テストが書きにくいと感じたら設計のフィードバックとして受け取る（Ch.7, 8）
5. バグ修正のときにまず再現テストを書く（Ch.10）特に5番目──バグ修正TDD──は、今日からすぐに始められる。バグが報告されたら、まず再現テストを書く。テストが Red になることを確認する。バグを修正して Green にする。これだけで、TDD のリズムが体に染み込み始める。
TDDの本当の価値
最後に、TDD の本当の価値について。
TDD の価値は「テストカバレッジを上げること」ではない。「バグを減らすこと」でもない（それは嬉しい副産物だが）。
TDD の本当の価値は、変更への自信だ。
テストがある状態：
「この変更で何かが壊れたら、テストが教えてくれる」
→ 大胆にリファクタリングできる
→ 新機能を安心して追加できる
→ 技術的負債を計画的に返済できる
テストがない状態：
「この変更で何が壊れるか分からない」
→ リファクタリングが怖い
→ 新機能が既存コードに悪影響しないか不安
→ 技術的負債が積み上がる一方TDD は「変更を恐れないソフトウェア」を作る方法だ。そして、変更を恐れないソフトウェアだけが、長期間にわたって進化し続けることができる。
参考文献・情報源
書籍
- Kent Beck 著、和田卓人 訳『テスト駆動開発』（オーム社、2017年） ── TDDの原典。本記事の理論的基盤
- Kent Beck『Tidy First?』（O’Reilly、2023年） ── リファクタリングの判断基準
- Martin Fowler『Refactoring』（Addison-Wesley、2018年 第2版） ── リファクタリングの技法カタログ
- Gerard Meszaros『xUnit Test Patterns』（Addison-Wesley、2007年） ── テストダブルの分類体系
記事・ポッドキャスト
- Kent Beck「Augmented Coding: Beyond the Vibes」（Tidy First, 2025年） ── Augmented Coding の提唱
- Gergely Orosz「TDD, AI agents and coding with Kent Beck」（The Pragmatic Engineer, 2025年） ── Kent Beck の最新TDD観
- Jason Gorman「Why Does TDD Work So Well in AI-Assisted Programming?」（Codemanship, 2026年1月） ── AI + TDD の理論的根拠
- DHH「TDD is Dead. Long Live Testing.」（2014年） ── TDD批判の原典
- Martin Fowler「Is TDD Dead?」（martinfowler.com, 2014年） ── TDD論争のまとめ
ツール・フレームワーク
- Vitest ── 本記事で使用したテストランナー
- Testing Library ── UIテストのベストプラクティス
おわりに
「テストを先に書けない」──この状態から始まった旅が、ここで一つの区切りを迎える。
本記事で伝えたかったのは、TDD が「テストを先に書く規律」ではなく、**「ソフトウェアの振る舞いを定義し、その定義に導かれて設計を発見するプロセス」**だということだ。
テストを書くことは手段であって目的ではない。テストが駆動する先にあるのは、信頼できる設計と、変更への自信だ。
そして、AI がコードを書く2026年の今、テストは人間の意図をソフトウェアに伝える最も信頼できる言語になっている。
テストを先に書けるようになった今日から、あなたのコードは変わり始める。