初記事は、いろいろ迷ったのですが、プログラムのテストについて語りたいと思います。
ちなみに、テストについては勉強しようと思っていますが、他の勉強ばかりしていて後回しになっています…
なので、素人の考えです。
テストと一言で言っても、思い浮かべることは、人によっていろいろだと思います。
私が浮かぶのをざっと挙げると、下みたいな感じです。
どんな開発プロジェクトであったとしても、テストにはそれなりの費用をかけているのだと思います。
ただ、テストへの力の入れ方を間違うと、いずれそのプロジェクトは破綻してしまうのではないか、と私は思ったりします。
単体テストの自動化は、どんどん導入するべきだと私は思いますが、古くから保守しているシステムだと、プログラム構造的の問題から単体テストが導入できないケースがあると思います。
（『エリック・エヴァンスのドメイン駆動設計』でアンチパターンとして挙がっている「利口なUI」ばかりのシステムとか）
そのシステムを書き換える（リファクタリングする）決定を通す風土が、チームや企業にあれば、メンバーやシステムにとって幸せでしょうが、テストの量を増やすことで保守し続けるという決定を下されるとします。
テストをたくさんする、という決定は一見問題ないように見えます。
ユーザーに対して、「このシステムは、この変更に対してこれだけの人数で、これだけテストしているから絶対大丈夫です！」と言うこともできるでしょう。
開発量をd、テスト量をtとしたら、「t = d * (係数)」とでも表したとします。
しかし、例えばこのシステムに対して「次回はdが３倍になる」改訂が加わるとしたら、tも３倍になるのでしょうか？
これは、確実にNoです。
上の係数は、一定値ではなく、dに関連して大きくなります。
結果として、tは指数関数的に増大します。
非常に単純な例を挙げると…
条件分岐１つに対し、必要なテストは「２」パターンです。
条件分岐が３つになったら、必要なテストは「８」パターンです。
たかが８パターンなら、問題ありません。
現実には、３つの条件分岐が９つになることもあります。
そのとき、先述のチームはテスト量を増やすことで、この改訂を乗り切ることができるのでしょうか…？ご想像にお任せします。
もう一つ、別の側面から見ます。
このシステムは、ユーザーから、要望等を多く受けているとします。
要望に応じて改訂を加えるということは、自ら「テスト量を増やす」という決定を下すことです。
外部から、提供時期に関して何らかの圧力があるとしたら（普通ありますが）、要望をかなえるために自ら工数を増やす決定を下すでしょうか？まず確実に、要望は後回しにすると思います。
そうすると、どれほど優れたシステムであっても、ユーザーはいずれ愛想を尽かして離れてしまうかもしれません…
まぁ、すべて想像に過ぎませんが。
私が思うのは、安直にテストを増やせばいいというのではなく、もっと前から手は打てるんだよ？ということです。
品質を保つには、リファクタリングしたり、テストを自動化したり、いろんな打つ手があるのだと思います。
テストと実装時間の関連については、『人月の神話』にも書かれているので、そちらを読むのもよいかもしれません。
では(´・ω・)ﾉｼ
