【てすとくどうかいはつ】
TDD(テスト駆動開発) とは?
最終更新:
💡 「答え合わせを先に作ってから、答えを書く」開発手法
小さな機能ごとに先にテストを書き、失敗を確認してから実装し、成功を保ちながらコードを整理する開発手法。Red→Green→Refactorのサイクルを繰り返す。
📌 このページのポイント
- 小さな機能ごとに、テスト→最小限の実装→コードの整理を繰り返す
- Redでは意図した理由で失敗することを確かめる
- Greenの後も既存のテストを通し、動作を保ってリファクタリングする
- テストを先に考えることで、使い方や設計を具体化する助けになる
動くコードがないのに、先にテストを書けるの?
書けるよ!例えば「add(2, 3)は5を返してほしい」と、使い方と期待する結果を先に書くんだ。作りたい機能の小さなゴールを決めてから、そのゴールを満たすコードを用意するよ。
Red→Green→Refactorって具体的には?
Redは、小さなテストを書いて意図した理由で失敗することを確認する段階。Greenではそのテストを通す最小限の実装を書く。Refactorではテストの成功を保ちながら、実装やテストの重複・分かりにくさを整理するよ。次の小さな機能でまた繰り返すんだ。
失敗すれば、どんな理由でもいいの?
違うよ。期待する機能がまだないから失敗したのかを見るんだ。テストの書き間違いや環境の問題では、狙った確認にならない。最初から通った場合も、すでに機能があるのか、テストが適切なのかを確かめよう。
一つ通れば完成?
今までのテストも通ることを確かめるよ。そして整理する段階を省かないことも大切。テストを先に書くだけで終わると、つぎはぎのコードが残ることがあるんだ。最初にテストしたいケースの一覧を作り、小さいものから進めると考えやすいよ。
TDDならバグがなくなるのかな?
書いたテストが確かめた範囲について、変更の影響を見つけやすくなるよ。でも抜けたケースや、画面全体・外部サービスとのつながりまで自動で保証するわけではない。TDDのサイクルと、ほかに必要な検証を組み合わせよう。
まとめ:ざっくりこれだけ覚えればOK!
TDDって出てきたら「テストを先に書いてから実装する開発スタイル」と思えばだいたいOK!
📖 おまけ:英語の意味
「Test-Driven Development」 = テストに先導される開発
💬 Kent Beckが1990年代後半にXPの一部として発展させ、著書Test-Driven Development: By Exampleでも説明した手法だよ。出版社の初版情報は2002年刊行となっているんだ。