テスト駆動開発（TDD）とは
テスト駆動開発（TDD：Test-Driven Development）は、実際の製品プログラムを書く前に、まず「そのプログラムが満たすべき仕様を確認するテストコード」を先に書き、そのテストに合格するように少しずつ製品プログラムを実装していくソフトウェア開発の手法です。「①失敗するテストを書く（Red）」「②テストを通る最小限のコードを書く（Green）」「③コードを綺麗に整理する（Refactor）」という3つのステップ（サイクル）を小刻みに繰り返すことで、バグが少なく、設計のクリーンなソフトウェアを安全に作ることができます。
具体例
例えば、「入力された2つの数値を足し算する関数」を作る場合、まず「足し算の関数に2と3を渡したら、結果が5になること」を確かめるテストを先に書きます。この時点では中身の関数が空なのでテストは失敗します（Red）。次に、急いで「2 + 3 = 5」を返すような単純な処理を書いてテストを合格させます（Green）。最後に、どんな数値でも動くように関数を整理・修正します（Refactor）。
【TDDのサイクル】\n1. Red : テストを先に書いて実行し、失敗（赤）させる\n2. Green : テストを合格させるための最もシンプルなコードを書いて成功（緑）させる\n3. Refactor: 重複コードの排除や整理を行い、より綺麗なプログラムにする（テストは通したまま）もう少し詳しく
TDD（Test-Driven Development）の極意は、ステップ幅を極限まで小さくし、「動作する綺麗なコード（Clean code that works）」を生み出すことにあります。「Red」ステップでは、これから作る機能の仕様を明確にするためにテストコードを書きます。テストが失敗することを確認することは、テストコードが正しくエラーを検知できる（＝テスト自体が正しく動作している）ことを保証するために極めて重要です。「Green」ステップでは、エレガントである必要はなく、テストをパスするためだけの「その場しのぎの最小限のコード」を書きます。定数をそのまま返すような仮実装でも構いません。これにより、開発者は「動作するコード」という確固たる足場を早期に得ることができます。「Refactor」ステップでは、すでにテストが通っている（安全網がある）状態を利用して、変数の命名整理、重複コードの排除、デザインパターンの適用などを行い、コードの読みやすさと保守性を高めます。このサイクルを数分〜数十分単位で高速に回転させることで、開発者は常に「動くこと」を確認しながら、精神的な余裕を持って綺麗な設計を追求できます。
試験でのポイント
応用情報技術者試験では、ソフトウェア開発手法やアジャイルプラクティスの一環としてTDDが出題されます。「製品コードを記述する前にテストコードを作成し、そのテストを通るように製品コードを実装し、その後にリファクタリングを行う開発手法」という順序（Red ➔ Green ➔ Refactor）を正しく理解しているかが問われます。また、TDDの目的が「単なるデバッグ作業の自動化」だけでなく、「プログラムの設計を洗練させること（テストしやすいコードは自然と疎結合で良い設計になる）」にあるという点を選択させる問題も頻出です。さらに、TDDを行うことで、開発の進捗が「テストの合格数」という客観的な指標で測定しやすくなり、手戻りのコストを大幅に削減できるというプロジェクト管理上のメリットも意識しておきましょう。
関連する用語
コードの振る舞いを変えずに内部構造を整理するリファクタリング、アジャイル開発プラクティスの源流であるXP（エクストリームプログラミング）、およびテストを自動実行して品質を維持するユニットテスト（単体テスト）があります。これらとTDDのサイクルを結びつけることで、アジャイルな実装手法の理解が深まります。