2003年、Kent Beckは『テスト駆動開発』を出版しました。「テストを自動化する」という話ではありません。不確実なプログラミングという作業の中で、一歩ずつ理解を深め、設計を導き出すためのワークフロー。Beckが書いたのはそういう本でした。
核心は、分析・設計・実装を時間軸で切り離し、小さな歩幅で繰り返すことにあります。
- **分析（テストリスト）**── 解くべき問題を「期待される振る舞い」としてリストアップする
- **インターフェースの設計（テストを1つ書く）**── リストから一つ選び、「どう呼び出されるのが理想か」を決める
- **実装（テストを成功させる）**── 設計の良し悪しは脇に置き、振る舞いの実現だけに集中する
- **実装の設計（リファクタリング）**── 動作が保証された状態で、初めて内部構造を整える
一度に一つのことだけに集中する。問題を解きながら設計が立ち上がってくる。オーバーエンジニアリングも、設計の放棄も、このリズムが防いでいました。
しかし「TDD」が広まる過程で、このプロセスの大半が消えました。残ったのは「実装の前にテストコードを書く」というステップ2だけです。最初の分析（テストリスト）も、最後の設計改善（リファクタリング）も省かれた。
「設計が固まっていないのにテストは書けない」「テストを書いても設計の質が上がらない」── 分析と設計のステップを飛ばして「テスト」だけを持ち込めば、そうなります。
Beck自身がこう書いています。
"If you are critiquing TDD and you are not critiquing my workflow, you are critiquing a strawman."
「もしもあなたがTDDを批評しようとしていて、かつ、私のワークフローを批評対象としていないのであれば、あなたは藁人形論法を使っていることになる」1
「問題をどう解くか」というプロセスが、「先にテストを書く」というルールに置き換わる。RESTと同じ構造がここにもあります。
source: https://gist.github.com/smeghead/61bdc57c2499389d84ae0fce91c2a57b