テストを先に書くと何が変わるか：Kent Beck『テスト駆動開発』

テスト駆動開発（TDD）は「テストを先に書くこと」として知られているが、その本質はテスト手法ではなく設計手法だ。Kent Beck の『テスト駆動開発』は、TDDの発案者が自ら書いた原典であり、技法の背後にある思想を理解するための一冊だ。

1. Red-Green-Refactorのサイクル

TDDの基本サイクルは3段階だ。

Red: 失敗するテストを書く。まだ実装が存在しないので、テストは当然失敗する。

Green: テストを通す最小限の実装を書く。この段階では「きれいなコード」である必要はない。動けばよい。

Refactor: テストが通ったまま、コードを改善する。重複を取り除き、意図を明確にする。

このサイクルを数分で一周する。「大きな問題を小さなテストに分解し、一つずつ解決していく」という作業の分解方法がTDDの実質だ。

2. ベイビーステップという姿勢

本書が繰り返すのは「小さく進む」という原則だ。

一度の変更が大きいと、テストが失敗したときに問題の場所が特定しにくい。変更範囲を極端に小さく保つことで、フィードバックのサイクルが速くなり、行き詰まったときに戻るべき地点が近くなる。

「Fake it till you make it」という手法はこの考え方の極端な表れだ。テストを通すためにベタ書きの定数を返す実装から始め、その後のリファクタリングで一般化する。まず動かすことを優先し、きれいにするのを後回しにする。

3. TDDは設計への圧力だ

テストが書きにくいとき、それは多くの場合、設計の問題を示している。

依存が多く、セットアップが複雑なクラスはテストが書きにくい。テストを先に書こうとすることで、設計の問題に早期に気づける。テストを後から書く開発と比べ、設計の改善を促す圧力としてTDDは機能する。

テストが書きやすいコードは、概して「一つのことをする」「依存が少ない」「振る舞いが明確」という特性を持つ。TDDを実践するうちに、設計判断の感覚が育つという側面が本書では重要な主張の一つだ。

4. 「動作するきれいなコード」という目標

本書が示す目標は「動作するきれいなコード（Clean Code That Works）」だ。

「動作する」と「きれい」の両方を一度に達成しようとすると、どちらも不完全になる。TDDはこれを二段階に分ける。まずGreenで動かし、次のRefactorできれいにする。

「きれいにする前に動かせ、動かせる前にきれいにするな」という順序は、作業の分解方法として単純だが、実践するには一種の鍛錬が必要だ。本書はその鍛錬の記録でもある。

DevBookPath のマップで確認する

この本の前後の読書順は、DevBookPath のグラフで確認できます。

👉 ソフトウェア設計の地図を見る

---

本記事のリンクには Amazon アソシエイト等の広告が含まれる場合があります。リンク経由の購入で運営者に紹介料が支払われることがあります。