テスト駆動開発

TDD（Test-Driven Development / テスト駆動開発）は、先に テスト を書き、それを通すように本体のコードを書く 開発の進め方です。「コードを書いてからテスト」という、ふつうとは逆の順番が特徴です。

TDDは、小さなサイクルを繰り返します。

flowchart LR
  R["Red：失敗するテストを書く"] --> G["Green：通す最小限のコードを書く"]
  G --> RF["Refactor：整理する"]
  RF --> R

1. Red … これから作る機能の、テストを先に書く。まだ実装がないので失敗する（赤）。
2. Green … そのテストを通す、最小限のコードを書く（緑）。
3. Refactor … 動作を保ったまま、コードを リファクタリング する。

この進め方には、いくつもの利点があります。

• 仕様が先に固まる … 「何ができれば正解か」を、テストとして明確にしてから作る。
• 常にテストがそろう … 自然と、テストのある状態が保たれる。
• 安心して手を入れられる … いつでも、壊れていないか確認できる。
• 作りすぎを防ぐ … テストを通すのに必要な分だけ、コードを書く。

最初は回りくどく感じるかもしれませんが、慣れると「動く確信を持ちながら、小刻みに前進できる」進め方です。