TDDについて

１年くらい更新が滞ってました。
土曜にTDDBootCampというイベントがあって、
非常に楽しかったのと非常に有益だと感じたので
ブログに書いて、シェアできないかと思った次第です。

そもそもTDDって何かについて。
Test Driven Developmentの略でテスト駆動開発といいます。

http://www.amazon.co.jp/Test-Driven-Development-Embedded-Pragmatic-Programmers/dp/193435662X

私自身の問題意識としては仕事で、作ったプログラムをCin(あるいはコミット)するまでの
開発サイクルがあまりに長いのが何とかならないものかというものがあって、
TDDBootCampに参加しました。

開発サイクルが長いと以下の問題があります

・一度にCin(あるいはコミット)するファイルの数が増えるので、バグの混入率が上がる
・上記バグにより手戻りが増え、デバッグのための開発コストが増える
・デバッグというのはいつ終わるか見通しがつきにくく工数見積もりの精度が下がる
・そもそも長期間でスケジュールを立てるので、なかなか正確な工数見積もりができない


結果として、プロジェクトの遅延と残業超過、開発者の心身荒廃につながります。

私のいる環境は気軽にCin(あるいはコミット)できる環境ではなく、
一つの対応をCin(あるいはコミット)するのに最短でも３日、通常で１，２週間、
ひどいときだと１ヶ月以上ファイルをローカルに持ち続けていることがあり、
かなり酷い目（鬼残業デバッグ）に会っています。

それに対して、TDDはその名のとおり、テストを最初に作ります。
サイクルとしては以下の１～３のとおりです。


１．プロダクトコードではなくテストコードを最初に書きます。

２．このテストコードはテストとしては失敗する状態のもので、
そのテストが成功するようにプロダクトコードを書いていきます。

３．テストが動いた（成功した）時点で、
すぐにファイルをCin(あるいはコミット)できるというところにあります。


１～３の小さなサイクルを繰り返していくのです。


以下に私がTDDのメリットだと思うことをあげます。

（１）テストを最初に書くので、最初にきちんとユースケースを意識することになり、
開発後半でのユースケース漏れする確率が減ります。

（２）失敗するテストコードが成功するまでプロダクトコードを書くので、
プロダクトコードを書いてからテストコードを書く場合に比べて、
テスト漏れやミスが起きにくいです。

（３）テストが動いた（成功した）時点で、
すぐにファイルをCin(あるいはコミット)できるので、
一度に大量にCin(あるいはコミット)する場合よりもミスや手戻りが減ります。


テストを最初にやって、開発初期の段階で
テスト結果により即フィードバックをもらいながら
小さいサイクルで物を作っていこうというものです。
バグは発見が遅れれば遅れるほど指数関数的にデバッグ・修正コストが増大していきます。
逆に言うと開発初期の段階で見つけることができれば、
プロジェクトの遅延も残業コストの低減にも開発者の健康にもつながるのです。
（TDDだけで上記が達成できるとは言いませんが）

ただ、言うことと実際にやることは全く以って異なるので、
今回TDDBootCampForC++に参加しました。
長くなったのでTDDBootCampForC++については別に書きます。