テスト駆動開発（TDD）ってそういうことだったのか
XPにおける「テストファースト」とか、「テスト駆動開発（Test-Driven Development）」については考え方もメリットも知識として理解しているつもりであるが、自分で試したことはなかった。利点は理解しつつも、テストコードを作成するためのオーバヘッドをどう見積もるかとかそんなことばかり考えていて、いまいち腹に入ってなかったのだけど、自分で試してみて（といっても数時間だけど）よく分かった。僕が自分でプログラムを書くときには基本的にTDDでいこうと思う。
たぶんTDDをはじめるために必要なことは、「プログラム中の動作確認のために書いているダミーコードを、テストフレームワークが規定する書式で書く」というだけのことなのだ。したがって、「規定の書式」を理解するための労力（数十分だ）以外は、これまでの開発と大差はない。しかも、こうすることでこれまでは捨てていたダミーコードやダミーデータをテストハーネスとして継続的に再利用できる。また、「規定の書式」で「標準化」されるため、マネジメント面のメリットも大きい。
たとえば、プログラムを書くときにこんなことをしていないだろうか？もし、こんな進め方をしているのなら、迷わずTDDに移行したほうがいい。
ありがちだけど「いまいち」な進め方の例
TDDで作成するテストコードというのは、要するに手順の２番目で書いているダミーのコードのことだ。このダミーコードをテストフレームワークの規定する書き方で書きましょうというだけのこと。上の手順では、手順の４番目でコメントアウトして捨ててしまっているが、TDDではテストコードとして外出しにされているので、削除する必要はない。これにより、いつでも何度でも同じテストを自動実行することができるようになり、結果としてリファクタリングが容易になるというわけだ。
大規模なプロジェクトに適用するとなると、いろいろと障壁も多いとは思うが、それ以前にプログラマ個人レベルで導入してもメリットは大きいんじゃないかな。リファクタリングしやすいということで、Ver1.0時点での品質の向上が期待できる。また、コーディング→テスト（OK）のサイクルが15分おきに回るというのは達成感が得やすく、気持ちいい。
ピンと来ない人は、だまされたと思って、とりあえずやってみたらよいと思う。やはり、手を動かすのは大切。
＃PerlとRubyでの実践のための情報はのちほど追記します。
個人的にもうちょっと考えたいのは、「TDDにおけるテスト」を「品質保証のためのテスト」として扱ってよいのか？という点。「TDD」はあくまで開発手法で、テスト技法ではない。したがって、テスト自動化の文脈で語ると危険な気がする。と思って、ググったら参考になりそうな記事（テスト駆動開発のテストは、テストか？−TDD から BDD へ）を発見。つづきはまた今度。
