実際には、より上位のテストを優先的に書こうという話。
http://d.hatena.ne.jp/yach/20140424
僕は以前から、ユニットテスト偏重なTDDの考え方に疑問を持ち、自分でテストを書くときは、なるべく上位のテストを書くようにしていました。
この考え方は、テストファーストな人達の評判が悪く、開発の方針を決める際に「なるべく大きな単位でテストを書くべきだ」という主張が通ることはほとんどありませんでした。
彼らの主張はこうです。
「ユニットテストを書け」「ターゲット以外はモック化しろ」。
そして、ときにはこの考え方が拡張されて、「ユニットテストを書きやすいようにクラスを設計しろ」となり(これは良いと思います)、「ユニットテストしにくいからコントローラーになるべくコードを書くな」とか言い出します。これは流石に本末転倒です。
こうして書かれたユニットテストというのは、開発者の思い込みでモックやスタブを書いてしまうので、結合テストでボロが出ることが多いです。「そんな値が来るとは・・・」というバグが多発するのです。
なんで上位のテストを書くの？
ソフトウェア開発の世界にはVモデルという考え方があります。
適当に図を書くとこんな感じになります。
このV字の上の方が、より重要でプロジェクトに対する影響度が高いという話しです。そして、これは工程の後ろの方、テスト工程にも言えることで、こちらの場合、より下流の工程の方が重要になります。
余談になりますが、「基本から学ぶソフトウェアテスト」という本では、プロジェクト発足と同時にテストチームを組織して、各工程に対応したテスト仕様書を設計書と同時に作成することをお勧めしていました。(ちなみにこの本、僕が読んだ10年ぐらい前の時点で既に内容が陳腐化していて、かつ、すごく退屈な本だったので買ってまで読む必要は無いです)
純粋なユニットテストとは、この図の「製造→UT」の部分にフォーカスを当て、「コーディング→フィードバック」のスピードを極限まで高めようという話かと思います。
これはこれで重要だとは思いますが、所詮は開発の中で閉じた話なので、効率化の枠がそもそも小さいのです。
説明としては以上となりますが、このV字モデル、暗黙的にウォーターフォールを前提としているため、そこがイマイチです。しかし、アジャイル開発というのは、本質的に「規模のデメリットが顕在化しない程度に開発を分割する」というプラクティスなので、小さいウォーターフォールがいっぱい連続していると取れます。
この1個1個のV字に於いて、テストを書くのであれば、なおさら上位のテストを書いていった方が効率的で素早く開発ができるでしょう。
結論
最近は、ツール類も充実してきていますし(DHHも言っていますが、Capybaraとか最高ですよね)、今までユニットテストが受け持っていた部分は、なるべく型によるプログラミングで置き換えようという動きも活発になってきているようです。
なので、これからは、自動テストと言えば、なるべくEnd-to-endで書くテストのことを指し、プログラミングレベルでのテストは、可能な限り型安全なスタイルに寄せていくという方向になっていくのではないでしょうか。
