対象試験と出題頻度
テスト駆動開発（TDD）は、基本情報技術者・応用情報技術者で出題されるテーマです。
アジャイル開発やXP（エクストリームプログラミング）に関連する開発技法として定番化しており、「先にテストを書く」という独特の進め方や、レッド・グリーン・リファクタリングの3ステップを正確に理解しているかが問われます。
詳細をクリックして確認
基本情報技術者
応用情報技術者
★★★☆☆
ランクB（標準）覚えておくと有利
用語の定義
情報処理試験を勉強していると、「テスト駆動開発って、普通のテストと何が違うの？」と混乱しがちです。
テスト駆動開発（TDD：Test-Driven Development）とは、一言で言うと
「先にテストコードを書き、それを満たすように実装を進めていくソフトウェア開発手法」
のことです。
イメージとしては、「採点基準を先に作ってから答案を書く試験」です。
普通の試験は「答案を書いた後に採点される」ものですが、もし「合格ラインの採点基準」を先に手元に置いてから答案を書けるとしたら、書く内容が明確になり、ムダな寄り道もなくなります。
TDDも同じ発想で、「このコードはこう動くべき」という合格基準（テスト）を先に書いてから、それを通すための実装を進めていきます。
📊 テスト駆動開発の基本情報
| 項目 | 内容 |
|---|---|
| 英語名 | Test-Driven Development（TDD） |
| 提唱者 | Kent Beck（ケント・ベック） |
| 関連手法 | XP（エクストリームプログラミング）、アジャイル開発 |
| 3ステップ | レッド → グリーン → リファクタリング |
解説
従来の開発では「コードを書いてから動作確認のテストを書く」のが一般的でした。
しかし、この順番だと「実装に都合のよいテスト」しか書かれず、仕様の抜け漏れに気づけないという弱点があります。
そこでKent Beckが提唱したのが、テストと実装の順番を逆転させる発想です。
仕様を満たすテストを最初に明文化することで、実装者は「何を作るべきか」に集中でき、設計のブレも減ります。
3つのサイクル：レッド・グリーン・リファクタリング
TDDの中核は、短い時間で繰り返される3ステップのサイクルです。
🔄 TDDの3ステップサイクル
① レッド（Red）
失敗するテストを書く
まだ実装がないので落ちる
② グリーン（Green）
テストを通す最小実装
きれいさは後回しでOK
③ リファクタリング
動作を変えず構造を改善
テストが通る状態を維持
▲ ③が終わったら次の機能の①へ。これを小さく繰り返すのがTDDの基本
具体例：足し算関数をTDDで作る
イメージしやすいよう、Pythonで「2つの数を足す関数」をTDDで作る流れを示します。
# ① レッド：先にテストを書く（この時点では add() が無いので失敗）
def test_add():
assert add(2, 3) == 5
assert add(-1, 1) == 0
# ② グリーン：テストを通す最小限の実装
def add(a, b):
return a + b
# ③ リファクタリング：型ヒントの追加など、動作を変えずに改善
def add(a: int, b: int) -> int:
"""2つの整数を加算して返す"""
return a + b
このように、最小単位で「失敗→成功→改善」を回しながら少しずつ機能を積み上げます。
関連する開発手法との比較
TDDを正確に位置づけるには、似たような名前の手法と区別しておくのが近道です。
| 手法 | 特徴 | 見分けキーワード |
|---|---|---|
| TDD | テストを先に書き、それを満たす実装を進める | テストファースト、レッド・グリーン |
| BDD | 振る舞い（仕様）を自然言語に近い形で記述してテスト化する | 振る舞い、Given-When-Then |
| ペアプログラミング | 2人で1台のPCを使って共同でコーディングする | 2人組、ドライバ、ナビゲータ |
| リファクタリング | 外部から見た動作を変えずに内部構造を改善する | 動作不変、構造改善 |
💡 TDDの核心を3行で
・テストを先に書き、それを通す実装を後から書く「テストファースト」の開発手法
・レッド（失敗）→グリーン（成功）→リファクタリング（改善）の3ステップを小さく繰り返す
・XPのプラクティスの1つで、Kent Beckが提唱した
では、この用語が試験でどのように出題されるか見ていきましょう。
試験ではこう出る！
TDDは、FE・APの午前問題でアジャイル開発・XPの関連用語として繰り返し出題されています。
📊 過去問での出題実績
| 試験回 | 出題内容 | 問われたポイント |
|---|---|---|
| AP H29春 午前 問49 |
テスト駆動開発の説明として適切なものを選ぶ問題。 | ・「先にテストケースを作成し、そのテストをパスするコードを記述する」が正解 ・トップダウンテスト・統合テストの説明がひっかけ |
| FE H30秋 午前 問50 |
XPのプラクティスに関する問題でTDDが選択肢の1つとして出題。 | ・XPの開発プラクティスとしての位置づけ ・ペアプログラミング・リファクタリングとの関係 |
| AP R元秋 午前 問49 |
アジャイル開発の手法・プラクティスを問う問題。 | ・テストファーストの考え方 ・ウォーターフォールとの違い |
📝 IPA試験での出題パターン
パターン1：「TDDの説明を選べ」
4つの選択肢の中から、テストファーストの考え方を表す説明を選ぶ形式。ひっかけとして「上位モジュールから順にテストする」（トップダウンテスト）、「全モジュールを結合して一括でテストする」（ビッグバンテスト）、「テスト工程の最後に総合的に確認する」といった通常のテスト技法の説明が紛れ込む。キーワードは「先にテストを書く」「パスするコード」。
パターン2：「XP・アジャイルのプラクティス」
XPの12のプラクティスの中にTDDが含まれており、ペアプログラミング・リファクタリング・継続的インテグレーションなどとセットで問われる。「テストファースト」と「TDD」がほぼ同義として扱われる点に注意。
試験ではここまででOKです。レッド・グリーン・リファクタリングの順番だけ確実に押さえれば、深追いは不要です。
【確認テスト】理解度チェック
ここまでの内容を理解できたか、簡単なクイズで確認してみましょう。
Q. テスト駆動開発（TDD）の説明として、最も適切なものはどれでしょうか？
- A. 上位モジュールから順に下位モジュールへとテストを進めていき、未完成の下位モジュールはスタブで代用する開発手法。
- B. 実装すべき機能のテストコードを先に作成し、そのテストをパスする最小限の実装を行った後、コードを改善していく開発手法。
- C. すべてのモジュールを一度に結合してテストを行い、全体の動作を一気に確認する開発手法。
正解と解説を見る
正解：B
解説：
TDDは「失敗するテストを書く（レッド）→テストを通す最小実装をする（グリーン）→動作を保ったままコードを整える（リファクタリング）」の3ステップを繰り返す手法です。選択肢Bはこの流れを正しく表現しています。
選択肢Aはトップダウンテストの説明です。これは結合テストの戦略の1つであり、開発手法そのものを指すTDDとは別の概念です。選択肢Cはビッグバンテストの説明です。一括結合してテストする手法であり、TDDの「小さく繰り返す」という思想とは正反対のアプローチになります。
よくある質問（FAQ）
Q. TDDを導入すると開発スピードは遅くなりませんか？
短期的には書くコード量が増えるため遅く感じます。ただし中長期では、テストが「動く仕様書」として残り、変更時のデグレード（既存機能の破壊）を即座に検知できるため、保守フェーズの工数が大きく削減されます。Microsoft社やIBM社の事例研究では、TDD導入後に欠陥密度が40〜90%低下したとの報告もあります。試験対策としてはここまでの数字を覚える必要はなく、「品質向上に寄与する」と理解すれば十分です。
Q. ユニットテストとTDDは同じ意味ですか？
違います。ユニットテストは「個別のモジュールが正しく動くか確認するテスト工程の名前」です。TDDは「ユニットテストを先に書いてから実装する開発の進め方」を指します。つまりユニットテストは”何を”、TDDは”いつ・どう書くか”を表す用語であり、レイヤーが異なります。TDDを実践すると結果的にユニットテストが大量に作られますが、ユニットテストを書いているからといってTDDをしているとは限りません。
Q. TDDで使われる代表的なテスティングフレームワークは何ですか？
言語ごとに定番があります。Javaなら「JUnit」、Pythonなら「pytest」「unittest」、JavaScriptなら「Jest」「Mocha」、Rubyなら「RSpec」「Minitest」、C#なら「NUnit」「xUnit.net」が代表例です。これらはxUnit系と総称され、Kent Beck自身が作ったSUnit（Smalltalk向け）が源流になっています。試験で具体名が問われることは稀ですが、JUnitの名前だけは選択肢に登場することがあるので押さえておくと安心です。
Q. TDDはウォーターフォール型開発でも使えますか？
原理的には使えますが、相性はよくありません。ウォーターフォールは「設計→実装→テスト」と工程を直列に進めるモデルであり、TDDの「実装とテストを小さく交互に繰り返す」思想と噛み合いません。そのためTDDはアジャイル開発、特にXPの文脈で語られるのが通例です。試験では「TDD＝アジャイル/XPのプラクティス」というセットで覚えておくと選択肢を絞り込みやすくなります。
