TDD（テスト駆動開発）
テストを先に書いてからコードを実装する開発手法。
📌TDDとは
TDD（テスト駆動開発）とは、テストを先に書いてからコードを実装する開発手法です。テスト＝プログラムが期待どおり動くかを自動で確かめる小さなチェックのことです。ふつうは「作ってからテスト」ですが、TDDはその順番を逆にします。
身近な例で考えると、料理の完成形（味の合格ライン）を先に決めてから調理するようなものです。「塩は何g・甘さはこのくらい」というゴールを先に紙に書き、それに合うように作っていきます。先にゴールがあるので、作りすぎや作り足りないを防げます。
上のツールで▶ボタンを押すと、失敗するテストから始めて、実装で通し、最後に整理するというTDDの流れを順番に確認できます。
🔁Red-Green-Refactor
TDDは「Red → Green → Refactor」という3つの段階を小さくくり返します。1サイクルはほんの数分で終わるくらい小さくするのがコツです。
・Red（赤）：これから作る機能のテストを先に書く。まだ実装がないのでテストは失敗（赤）する
・Green（緑）：テストを通すための最小限のコードを書く。テストが成功（緑）に変わる
・Refactor（リファクタリング）：テストが通ったまま、コードを読みやすく整理する
信号機にたとえると分かりやすいです。赤で止まり（失敗を確認）、緑で進み（通す）、そのあと身だしなみを整える（整理）。Refactorのあともう一度テストを走らせ、緑のままなら壊れていない証拠です。上のツールの中央の信号で、赤→緑の変化を確認できます。
✨利点
TDDには、開発を進めやすくするいくつかの利点があります。
・安全に修正できる：常にテストがあるので、直したあとに「壊れていないか」をすぐ確認できる。これが安全網になる
・仕様がはっきりする：テストが「こう動くべき」という仕様の見本になり、考えを整理できる
・バグを早く見つけられる：作りながら毎回テストするので、不具合が小さいうちに気づける
・作りすぎを防げる：テストを通すのに必要なコードだけを書くので、ムダな機能を作りにくい
自転車にたとえると、テストは補助輪のような存在です。補助輪があれば思い切ってこげるのと同じで、テストがあると安心して大胆にコードを書き直せます。上のツールのRefactor後にもう一度テストが通る様子が、まさにこの安全網の働きです。
📌なぜテストを先に書くのか
なぜテストを先に書くのか。それは、テストを先に書くことで「何を作るべきか（仕様）」をあいまいにしないためです。
ふつうの開発では「まず作る → あとでテスト」という順番です。この場合、作り終えてからゴールとのズレに気づくことがあります。大きく作り込んだ後で「動作が仕様と違う」と分かると、直すのが大変になります。
TDDではテストを先に書くことで、こうなります。
・ゴール（合格条件）を先に定義する：「この入力を渡したらこの出力が返ること」と最初に明確にする
・ゴールに必要な分だけ作る：テストを通すことだけを目標にするため、余計な機能を作らずに済む
・ズレをすぐ発見できる：テストが赤のままなら「まだゴールに届いていない」と一目で分かる
引越しに例えると、「新居に置きたい家具の配置図（テスト）を先に書いてから荷造りする（実装）」イメージです。先に配置を決めておくと、不要なものを持ち込まずに済みます。
📌TDDと従来開発の比較
| 従来の開発 | TDD（テスト駆動開発） | |
|---|---|---|
| テストを書くタイミング | 実装のあと（後付け） | 実装の前（先に書く） |
| ゴールの明確さ | 作りながら決まることも | テストで最初に定義する |
| バグに気づくタイミング | 作り込んだ後になりがち | すぐに赤で分かる |
| 安全に修正できるか | 不安になることがある | テストが安全網になる |
| 作りすぎのリスク | 余分な機能を作りやすい | テストを通す分だけ作る |
表のとおり、TDDは従来の開発と順番が逆です。この「テストを先に・実装をあとに」という順番の違いが、さまざまな利点につながっています。ただし、TDDはすべての状況で必ずしも最適というわけではありません。小さな修正や試作段階ではテストを先に書きにくいこともあります。TDDは「テストを大切にする文化」の一形態として理解しておきましょう。
