テスト駆動開発（Test-Driven Development: TDD）は、テストを書くことでソフトウェア開発をガイドするソフトウェア構築手法である。 1990年代後半にKent Beckがエクストリームプログラミングの一部として開発したものである。 基本的には、以下のシンプルな3つのステップを繰り返して実行する。

  • これから追加したい機能についてのテストを書く
  • そのテストをパスするまで機能のコードを書く
  • 新旧のコードをリファクタリングして適切な構造にする

テストケースのリストを書き出す
→ ひとつのテストを選択する
→ テストを書く（レッド）
→ テストをパスさせる（グリーン）
→ リファクタ
→ ひとつのテストを選択する

学んだことがあればリストを更新する

この3つのステップ（レッド・グリーン・リファクタと呼ばれる）がプロセスの中心だが、 最初にテストケースのリストを書き出すという重要なステップも存在する。 リストからテストをひとつだけ選択し、それにレッド・グリーン・リファクタを適用する。 それが終わったら、次のテストを選択する。 設計の重要なポイントまで素早く到達できるテストを選択したい。 テストに適切な順番をつけることはスキルである。 また、プロセスの途中でも思いついたテストをリストに追加すべきである。

テストを先に書くこと（XPの本では「テストファーストプログラミング」と呼ばれている）には2つの大きな利点がある。 わかりやすいのは、自己テストコードを手に入れる方法になることである。 なぜなら、テストをパスさせるためのコードを書くことしかできないからだ。 2番目の利点は、テストを先に考えれば、コードのインターフェイスから考えられるようになることだ。 インターフェイスとクラスの使い方にフォーカスすることで、インターフェイスと実装の分離ができるようになる。 このことは、多くのプログラマーが苦労している優れた設計に必要な重要な要素である。

TDDが失敗するのは、3つ目のステップを無視しているからだ。 コードをリファクタリングしてクリーンに保つことは、このプロセスの重要な部分である。 リファクタリングしなければ、コードの断片が散らかったままになるだろう （テストを書いているので、よくある設計の失敗よりは痛みは少ない）。

参考文献

KentによるTDDの標準的な方法はオンラインで読める重要なまとめだ。

さらに詳しく知りたい場合は、Kent Beckの著書『テスト駆動開発』を参照してほしい。

James Shoreの著書『The Art of Agile Development』のTDDの章は、TDDとアジャイル開発を接続するもうひとつの重要な説明である。Jamesは「Let’s Play TDD」というスクリーンキャストも提供している。

改訂

最初の投稿は2005年3月5日だった。Kentの投稿に触発されて、2023年12月11日に更新した。