参考：https://t-wada.hatenablog.jp/entry/canon-tdd-by-kent-beck
上の記事が勉強になったので要約してアウトプットしてみた。
テスト駆動開発（TDD）の本質とは？
テスト駆動開発（TDD）は、単に「プログラムを書く前にテストを書く」というルールではない。
それは 常に動作する綺麗なコードを着実に育てていくための思考フレームワークかつ開発手法 である。
その中心には 「Red → Green → Refactor」 と呼ばれる非常に短いサイクルの繰り返しがある。
Red → Green → Refactor のサイクル
-
Red (失敗):
まず作りたい機能に関するテストを1つだけ書く。この時点では機能が存在しないため、テストは失敗する（Red）。 -
Green (成功):
失敗したテストをパスさせるために、最小限のコードを書く。テストは成功に変わる（Green）。 -
Refactor (整理):
テストが成功している状態を保ちつつ、コードを綺麗で効率的に整理する。
→ この小さなサイクルを数分単位で繰り返すことで、「常に動く」という安心感を維持しながら開発を進められる。
よくある3つの大きな勘違い
勘違い1：「最初に"全部"のテストを書かなければならない」
- 誤り。TDDでは 実装したい機能リストから1つだけ選んでテストを書く。
- 一度に1つに集中することで、問題を小さくシンプルに保てる。
勘違い2：「設計をせずに行き当たりばったりでコードを書く手法だ」
-
これも誤り。TDDはむしろ優れた設計技法。
-
TDDは インターフェイス設計 と 内部構造の設計 を自然に分離させる。
- テストを書く段階: 「この機能はどう呼ばれたいか？」 → インターフェイス設計
- リファクタリング段階: 「どうすれば効率的になるか？」 → 実装の洗練
勘違い3：「TDDのリズムを無視して、後でまとめて実装すればよい」
- 最も本質から外れた考え方。
- TDDの力は Red → Green → Refactor の短いリズム にある。
- このリズムが 自信と安心感を与え、複雑な問題にも立ち向かう力 になる。
TDDの強力なセーフティネット：なぜ毎回すべてのテストを実行するのか？
TDDの重要なルールは
「コードを変更するたびに、過去のものも含めてすべてのテストを実行する」 こと。
- 過去のテスト群は、アプリ全体の品質を保証する セーフティネット。
- 新機能の追加やリファクタリングで 意図せず既存機能を壊す（デグレード） 可能性がある。
- すべてのテストを毎回実行することで、この問題を即座に検知できる。
→ 一見非効率に見えるが、結果的に開発速度と品質を大幅に向上させる。