テスト駆動開発（TDD）

📖 もうちょい詳しく

何が新しいの？

ふつうの開発では、先にプログラムを作って、あとから「ちゃんと動くかな？」と試験（テスト）をします。テスト駆動開発（TDD）はその順番を逆にして、先にテストを書いてから本体のプログラムを書きます。2000年ごろから広まった進め方で、作りながら品質を保つための工夫として知られています。

どうやって動いてるの？

TDDは「レッド → グリーン → リファクタリング」という3つの手順をくり返します。まず、まだ動かないので失敗する（赤＝レッド）テストを書きます。次に、そのテストが通る（緑＝グリーン）ように最小限のコードを書きます。最後に、動きを変えずにコードを整理（リファクタリング）します。この小さな一周を何度も回しながら、少しずつ機能を積み上げていきます。

何ができるの？

先に「何ができれば正解か」を決めてから作るので、作るべきものがはっきりします。あとから直したときも、ためたテストを走らせれば「うっかり別の場所を壊していないか」をすぐ確認できます。仕様の勘違いや手戻りを早めに見つけやすくなります。

🌱 身近なたとえ

料理で例えると、作り始める前に「完成したときの味見の基準」を先に決めておくようなものです。「塩加減はこのくらい」「とろみはこの程度」と合格ラインを紙に書いてから調理を始めます。味見をして基準を満たしたら次の工程に進む、という進め方に似ています。

✅ まず覚えるポイント

• 本体より先に、正しさを確かめるテストを書く
• 「失敗→成功→整理」の小さな一周をくり返す
• まず通すための最小限のコードだけ書く
• ためたテストで「壊していないか」をすぐ確認できる
• 作るべきものが先に固まり、手戻りが減りやすい

🧭 よくある勘違い

テストを先に書くと、二度手間で遅くなるの？

最初は書く量が増えて遅く感じることがあります。ですが、バグを早く見つけられたり、あとから直すときの確認が楽になったりして、全体ではかえって速くなる場合が多いです。特に長く使うプログラムほど効果が出やすいと言われます。

テストを書けば、バグはゼロになるの？

そうとは限りません。TDDで防げるのは「自分が想定した使い方での不具合」が中心です。想定していなかった使われ方や、テストの書き方そのものが間違っていれば、見落としは起きます。あくまで品質を保ちやすくする手段の一つです。

TDDと単体テストは同じもの？

近いですが別物です。単体テストは「部品ごとに動きを確かめる試験」という"もの"を指します。TDDはそのテストを"先に書いてから開発する"という"進め方"のことです。

🧩 関連して覚えると楽な言葉

• unit-test（単体テスト）: プログラムを小さな部品ごとに分けて動作を確かめる試験。TDDで先に書く対象になることが多い
• refactoring（リファクタリング）: 動きを変えずにコードを整理すること。TDDの3手順の最後にあたる作業
• agile（アジャイル）: 小さく作って確かめながら進める開発の考え方。TDDと相性がよい
• ci-cd（CI/CD）: 変更のたびに自動でテストや反映を回す仕組み。ためたテストを活かしやすくなる

🏁 ひとことでまとめ

ゴール（テスト）を先に決めてから作り、合格を確かめながら少しずつ進める開発のやり方です。