TDDは「粗にして広く」始めるのが良いのかも知れない。

■ テストは小さく始めて大きく育てる

　プロジェクトにテスティングフレームワークを導入するときは、「小さく始め」ます。まず特定の部分だけに対してテストを作成して、テストプログラムのメリットとトレードオフを実感してみてください。

実現場でTestNGを活躍させる“5”つのテクニック (3/3)：次世代テストフレームワークでテストを変える（3） - ＠IT

TestNGは興味深い。特に個々のテストについて「依存関係」という概念を採り入れたのは、より現実解を意識しているものと思われる。例えIFとMockで囲い込んだとしても、やはり「最初に呼ぶメソッド」で転けてしまうが為に、以降の数十・数百というassertが真っ赤に染まるのは見ていて気持ち悪い。

また引用にもあるが、最初からあらゆるクラスやメソッドに対してテストケースを作成するのは避けた方がよいのだろう。実際YakiBikiで最初に避けたのが"HTTP周りの入出力と絡む処理のテストケース"だった。これは書かない。何でかというと・・・書き方の見当がつかないし、よしんばSeleniumだのHttpUnitだのJMeterのassertだので書けるようになったらなったで、HTTPアクセスという外部からの観測でどうやってMockやテストデータの用意をすれば良いのか見当がつかないし、ついたところで「あれもこれも・・・」で際限なく膨れあがるのは目に見えている。CactusとかJavaのServletオンリーだけどイイ線行っているとは思うのだけれど。

結局TDDというのは「プログラマのやる気」を引き出すのが目的の一つなのだから、TDDを遂行しようとして頭を悩めてモチベーションを下げてしまうのは本末転倒も良いところだ。だったら、「頭を悩ますようなユニットテストは、ぶっちゃけ書くのを諦める」という選択肢だって当然あるはずだ。快感を感じる為にTDDを実施するのだから、気持ちよくなれそうな箇所だけ適用したって良いはずだ。

テストケースを書く時悩むのは、「手で確認する時はこうしていたけど、さてソフトウェアにそれをやらせようとするとどうすればよいのだろう？」という疑問だ。データを用意するのだって、人間が行う時はその時そのタイミングで柔軟にテーブルの中身から判別してデータを用意できるが、ソフトウェアにやらせようとするとソフトウェアにその判断をやらせようとしてしまう。
例えばログ出力をチェックするのだって、人間ならばコンソールを2つ3つ開いてtailさせておけば直ぐに観測と判断が可能だが、ソフトウェアにそれをやらせようとするのは頑張ればできるだろうが、簡単にコードに起こせるとは言い難い。

さらに言語によってツールも変わる。JavaとPHPでは当然違うわけだし、PerlとPHPでもテストツールの特性は異なる。よしんばOOPでない素のCやCOBOLはどうなる？

というわけで、なんだかTDDって考えれば考えるほど鬱になってくるなぁ・・・といいつつも、YakiBikiではTDDを一部使ってたりするのだけれど。そして実際、今Javaの業務Webシステム改修のお手伝いしているのだけれど、テストケースが無くてマジ不安だったりする自分がいるので、なんだかんだと愚痴をたれている割には徐々にTDDに染まっているのかなぁとか。