テスト駆動開発（TDD：Test Driven Development）は，アジャイル開発のプラクティス（実践手法）のひとつとして発展してきた。これには大きな意味がある。アジャイル開発は，さまざまな粒度での「フィードバック」を繰り返す手法である。顧客から，チーム全体から，システムから。それらのフィードバックのうち，システムからの最も小さいフィードバックを具現化したものが，TDDである。TDDは，開発者がビルドテストを繰り返し，現在作成中のプログラムからつねにフィードバックを受けつつ，開発を進めていく手法である。そのフィードバックループの時間は，数秒から数分程度の短いものである。
　TDDは，現在の開発環境だからこそ，成立する。コンピュータのCPUやメモリなどのリソースが貴重だった時代には，このような短い時間でビルドテストを繰り返す手法は，現実的ではなかっただろう。「短いフィードバック」は成立するべくもなかった。通常，コンポーネントレベルのビルドであれば，数秒以内で済むからこそ，何度も繰り返し行なえる。
　間違えてほしくないのは，アジャイル開発手法を採用しないからTDDも採り入れない，と判断するのであれば，非常にもったいないということである。たしかにTDDはアジャイル開発手法，そのなかでもとくにエクストリームプログラミング（XP：Extreme Programming）とともに発展してきたが，TDD単独で採用しても十分メリットのある手法である。とくにオブジェクト指向言語でTDDが実施しやすいというだけではなく，TDDを行なうことで，オブジェクト指向的にプログラムを考えやすくなるという意味も含んでいる。たしかに，ユニットテストツールの充実もあり，JavaやC#，C++でTDDが適用しやすいのは事実だろう。しかし，非オブジェクト指向言語，たとえばC言語でも，TDDを採用することでプログラムをコンポーネント化して考えやすくなる。
　ただし，新しい手法は何でもそうだが，TDDを適用するには開発者それぞれが，ある「壁」を乗り越えなければならない。これが意外にやっかいである。その壁とはHowからWhatへの思考方法の転換である。プロフェッショナルとしてのソフトウェア開発者がプログラミングを始める際には，何らかの「仕様」が示されていることがほとんどである。アジャイル開発の場合には，開発者が担当するタスクがそれにあたる。あるタスクを目の前にしたとき，開発者は通常どう考えるか。この仕様を「どうやって（How）」実現するかを考えるだろう。しかし，TDDを適用すると何が起こるだろうか。TDDでは，テストファーストとよばれる実装コードよりテストを先につくる方法を採る。この考え方に初めて触れる方は，試しにテストファーストで考えてみてほしい。「どうやって」より先に「どんな（What）」を考えなければ，テストはつくれないはずだ。
　より具体的にいうと，これからつくろうとするプログラムの「かたまり」は外から見てどのように使われるか（提供インタフェース），その「かたまり」がやるべきことをなすためにほかに何か必要か（要求インタフェース），つまり「かたまり」の入力と出力を考える必要がある。このおかげでコンポーネント指向が促進されるのではあるが，開発者には思考方法の切り替えが要求される。この壁を乗り越えるためには，知識と週刊の両方を転換すべきと考えている。
　知識の切り替えはいうまでもないだろう。TDDとは何であって，どんなふうに進め，その意義は何か，それを理解しなければ，自身の開発にTDDを適用することはできない。しかし，習慣の切り替えも必要になることを，忘れてはいけない。TDDは開発者の「習慣」である。習慣化させるためには，多少の時間を割いて，TDDを手に馴染ませなければならない。これは，知識としてTDDを理解するだけでは足りないポイントである。
　本書では，TDDをステップバイステップで進めていく。ぜひこのとおりに「写経」して，TDDを手に馴染ませてほしい。ただし，何も考えずに写経しているだけでは意味がない。ここは何をしているか，なぜそうしているか，つねに考えながら進めてほしい。そのうえで，自身の開発を進める際に，TDDの手法を適用してみてほしい。思考方法が変わっていることに気づくはずだ。TDDは，このように知識と習慣の両輪で身につけるべきという考え方の元に，本書は構成されている。
　TDDにもデメリットはあるし，ソフトウェアシステムのすべての部分にTDDが適用できるとはいえない。しかし，そのことを，TDDを理解・適用しないことの「言い訳」にしてはいけない。TDDは明らかにメリットがあるし，開発者が身につけるべきスキルのひとつである。本書を通じて，ひとりでも多くの開発者がTDDを使えるようになることを期待する。

2013年4月
著者しるす