ブログ記事
テストを先に書くと何が変わるか：Kent Beck『テスト駆動開発』
テスト駆動開発（TDD）は「テストを先に書くこと」として知られているが、その本質はテスト手法ではなく設計手法だ。Kent Beck の『テスト駆動開発』は、TDDの発案者が自ら書いた原典であり、技法の背後にある思想を理解するための一冊だ。
1. Red-Green-Refactorのサイクル
TDDの基本サイクルは3段階だ。
Red: 失敗するテストを書く。まだ実装が存在しないので、テストは当然失敗する。
Green: テストを通す最小限の実装を書く。この段階では「きれいなコード」である必要はない。動けばよい。
Refactor: テストが通ったまま、コードを改善する。重複を取り除き、意図を明確にする。
このサイクルを数分で一周する。「大きな問題を小さなテストに分解し、一つずつ解決していく」という作業の分解方法がTDDの実質だ。
flowchart LR
R["🔴 Red\n失敗するテストを書く\n（実装はまだない）"] --> G["🟢 Green\n最小限の実装で\nテストを通す"]
G --> RF["♻️ Refactor\nテストが通ったまま\nコードを改善する"]
RF --> R
style R fill:#fce8e8,stroke:#e53935
style G fill:#e8f8e8,stroke:#4caf50
style RF fill:#e8f4fd,stroke:#4a9eda
2. ベイビーステップという姿勢
本書が繰り返すのは「小さく進む」という原則だ。
一度の変更が大きいと、テストが失敗したときに問題の場所が特定しにくい。変更範囲を極端に小さく保つことで、フィードバックのサイクルが速くなり、行き詰まったときに戻るべき地点が近くなる。
「Fake it till you make it」という手法はこの考え方の極端な表れだ。テストを通すためにベタ書きの定数を返す実装から始め、その後のリファクタリングで一般化する。まず動かすことを優先し、きれいにするのを後回しにする。
3. TDDは設計への圧力だ
テストが書きにくいとき、それは多くの場合、設計の問題を示している。
依存が多く、セットアップが複雑なクラスはテストが書きにくい。テストを先に書こうとすることで、設計の問題に早期に気づける。テストを後から書く開発と比べ、設計の改善を促す圧力としてTDDは機能する。
テストが書きやすいコードは、概して「一つのことをする」「依存が少ない」「振る舞いが明確」という特性を持つ。TDDを実践するうちに、設計判断の感覚が育つという側面が本書では重要な主張の一つだ。
4. 「動作するきれいなコード」という目標
本書が示す目標は「動作するきれいなコード（Clean Code That Works）」だ。
「動作する」と「きれい」の両方を一度に達成しようとすると、どちらも不完全になる。TDDはこれを二段階に分ける。まずGreenで動かし、次のRefactorできれいにする。
「きれいにする前に動かせ、動かせる前にきれいにするな」という順序は、作業の分解方法として単純だが、実践するには一種の鍛錬が必要だ。本書はその鍛錬の記録でもある。
5. この本が解決できる具体的な状況
「テストを書くべきとはわかっている。でもどのタイミングで、どの粒度で書けばいいのかわからない」——この迷いを持つエンジニアに向けてピンポイントで書かれている。理論として TDD を知っているが、実際に手を動かせていない段階から実践に踏み出すための一冊だ。
実装ありきで後からテストを書く開発をしていて、「テストがあるのに自信が持てない」「リファクタリングするとテストが大量に壊れる」という経験が積み重なっているときに、問題の構造が見えてくる。
6. 向いている人・向いていない人
向いている人：
- TDD を理論では理解しているが、現場で実践できていない
- ユニットテストは書いているが、設計品質への貢献を実感できていない
- リファクタリングするたびにテストが壊れることに悩んでいる
向いていない人：
- テスト自体の書き方（JUnit / Vitest / pytest の基本 API）をまだ知らない（本書は TDD の思想書であり入門書ではない）
- テストより先に完成形の設計を考えてから実装したい人（本書の思想とは逆向きになる）
7. 読み終えた後のステップ
TDD のサイクルを身体で覚えたら、次は「何を、どの粒度でテストするか」という設計原則に進むと定着する。『単体テストの考え方/使い方』（Vladimir Khorikov）は、保守性が高く価値のあるテストを論理的に定義し、リファクタリング耐性を損なうアンチパターンを避ける実践ガイドで、TDD の小さなサイクルで得た「動くテストを書く感覚」を体系立てて整理してくれる。
あるいは、単体レベルの TDD に慣れたら、外側から駆動する TDD（受け入れテスト→単体）でオブジェクト間の協調そのものを設計する段階に進む道もある。『実践テスト駆動開発』（Steve Freeman, Nat Pryce）はモックオブジェクトを用いた相互作用テストを通じて、システムを外側の要件から内側の実装へと育てる高度な TDD 手法を解説しており、モックを実装の代用ではなく協調を表現する設計ツールとして使う視点が身につく。
筆者の体験から
テストはいつも後付けで書いていた。カバレッジを埋める順番が当たり前で、テストファーストを若手に勧めながら自分ではその感覚を説明できないことに気まずさを覚え、原典でRed-Green-Refactorを回してみることにした。
実践に持ち込んだのは「Fake it till you make it」だ。ベタ書きの値を返す実装から始め、テストが増えてから一般化する。正しい実装をいきなり書こうとして手が止まる時間が減り、ベイビーステップも小さくしたことで、テストが落ちたときに壊した箇所がすぐ分かるようになった。
その反面、依存の絡んだ既存コードにこの細かさを持ち込むと窮屈だった。レガシー改修では先に構造をほぐさないとテストの置き場所すら決められないことが多い。
料金計算ロジックの改修であえてベタ書きから始めたところ、境界値のケースを足した瞬間に通らなくなり、一般化を迫られる感覚を初めて味わった。若手に見せたら「先に全部の分岐を想定しなくていいんですね」と言われ、指導の仕方が変わっていたことに気づいた。
DevBookPath のマップで確認する
この本の前後の読書順は、DevBookPath のグラフで確認できます。
本記事のリンクには Amazon アソシエイト等の広告が含まれる場合があります。リンク経由の購入で運営者に紹介料が支払われることがあります。
この記事を共有
この地図を共有