// シス担のミカタ
システム開発

テスト駆動開発（TDD） てすとくどうかいはつ

TDD自動テストリファクタリング品質ユニットテストアジャイル
テスト駆動開発（TDD）について教えて

簡単に言うとこんな感じ！

「まずテスト（合格基準）を書いてから、それを通るコードを書く」という順番が逆な開発手法だよ！ テストを先に書くことで「何を作るべきか」が明確になり、バグが激減するんだ。料理で言えば「採点基準を決めてから料理を作る」みたいな感じ！

テスト駆動開発（TDD）とは

テスト駆動開発（Test-Driven Development：TDD）は、「先にテストを書き、次にそのテストを通過するコードを書き、最後にコードを整理する」というレッド・グリーン・リファクタリングの3ステップサイクルを繰り返す開発手法です。

従来の開発では「コードを書いてからテストを書く」という順番が一般的でしたが、TDDではこれを逆転させます。テストを先に書くことで、「どんな動作をするべきか」を最初に明確化でき、設計の質が高まります。また、全工程でテストが存在するため、コードを変更・追加した際に「既存の動作が壊れていないか」を即座に確認できます。

発注側の観点では、テスト自動化の仕組みが整備されているかは、システムの保守性と変更コストに直結します。テストがないシステムは、機能追加や改修のたびに「何か壊れていないか」の手動確認が必要になり、開発スピードが急速に低下します。

TDDの3ステップサイクル

ステップ名称内容
① Red失敗するテストを書くまだ実装がないので必ずテスト失敗
② Greenテストを通過するコードを書く最低限動くコードを素早く書く
③ Refactorコードを整理する重複削除・命名改善・設計改善

TDDのメリット・デメリット

観点メリットデメリット・注意点
品質バグが早期に発見されるテスト自体の設計スキルが必要
設計インターフェース設計が明確になる過剰な細分化に注意
速度後からのデバッグ時間が削減慣れるまでは時間がかかる
保守性リファクタリングが安心してできるテストの保守コストも発生
ドキュメントテストが仕様書代わりになるテストが仕様を正確に反映しているか注意

歴史と背景

  • 1999年 — ケント・ベック（Kent Beck）がSUnit（SmallTalk用テストフレームワーク）をJava向けに移植しJUnitを開発
  • 2000年 — ケント・ベックがエクストリームプログラミング（XP）でTDDを体系化・命名
  • 2002年 — ケント・ベック著「テスト駆動開発」（Test Driven Development: By Example）が出版。TDDのバイブルとなる
  • 2003年 — マーチン・ファウラーが「リファクタリング」の概念とTDDの関係を整理し普及に貢献
  • 2010年代 — TDDからBDD（振る舞い駆動開発）が派生。RSpec・CucumberなどBDDツールが登場
  • 2020年代 — AIコーディング支援でもテスト生成が可能に。TDDの考え方はAI時代でも有効

TDDのサイクル図

TDDのレッド・グリーン・リファクタリングサイクル 🔴 Red 失敗する テストを書く 🟢 Green テストが通る 最低限のコード ♻ Refactor コードを整理・改善 テストを通す 次のテストへ

関連する規格・RFC

※ TDD自体は標準仕様ではありませんが、以下の規格・フレームワークと深く関連しています。

フレームワーク内容
JUnit / pytest / RSpec各言語のユニットテストフレームワーク
BDD（振る舞い駆動開発）TDDを発展させた手法。ビジネス視点のテスト記述
ISO/IEC 25010ソフトウェア品質特性の国際規格

関連用語