テストが先か、コードが先か

Chris Matts氏はこの問題に対して興味深い視点を提示している。つまり、入ってくる情報の問題ととらえているのだ。受入テストをアップフロントに書かないソフトウェア開発プロセス（アジャイルに特化したものである必要は無い）を想定すると次のようになる。QAチームはいつも通りにテストシナリオを流し、欠陥が見つかればソフトウェア開発チームにフィードバックする。これらの欠陥はランダムに見つかるので、ソフトウェアチームの生産性にランダムに影響を与えることになる。それというのも、こういった欠陥に対応するために一定程度の工数が割かれるからだ。つまり開発チームに対して、新しい情報がランダムに入ってくるのだ。

ここで、QA部門によって書かれるこういったテストが、開発が始まる前に書かれたらどうなるかを考えて頂きたい。これらのシナリオによって提供される情報は、今やイテレーションの始めにおいて予見可能な形で現れるのであり、したがって不確実さが減り、生産性はより安定したもの（ランダムな妨害が減る）になる。つまり、より予測可能になるのだ。

http://www.infoq.com/jp/news/2009/06/automated-acceptance-tests

最初から、振る舞いがきっかり決まっているモノを作って、テストするのと、
なんだかあやふやなモノを作ってから、それがどのような振る舞いをするべきなのか考えて、テストするのとどちらが間違いや手戻りが少ないと思う？

そういう話なんだろう。