テストコードを書くコストに関する考察

昨年お世話になっていた職場の仕事仲間と先月ランチする機会があった。
自分の関わっていたプロジェクトはペアプロやTDDを実践していたのだが、残念なことに自分が抜けた後はテストコードを書かなくなってしまったという。

理由を聞くと「テストコードを書くより、動くプロダクトコードをどんどん書きたい」ということだった。
これは心情的にはよくわかる。
納期のプレッシャーが強く、TDDに慣れていない状況では特にそうだ。
要は「テストを書いてる暇なんかない」と判断してしまうわけだ。

TDDの最初の躓きのひとつとして、テストコードを書く手間が増えただけのように感じられるというものがあると思う。
実際に手間は増えている。
しかし適切なテストの書き方がよくわからないため、余分な手間をかけすぎているということもあるだろう。

例えばゲッターやセッターのテストを逐一書いてしまう。
これは実際に無駄なことであるから、このせいでテストコードを書くことは無駄であるとと感じてしまう感覚は正しい。
間違っているのはそれによってテストコードすべてが無駄であると判断してしまうことだ。

テストコードの手間を許容するにはどうしたらよいか。
それを書くコストよりも多くのコストを削減してくれると考えてみたらどうだろう。

テストコードのあるコードは必ずすべての回帰テストをクリアしたコードである。
テストコードのないコードはすべての回帰テストをクリアしてないかもしれないコードである。

これはシンプルで確かな事実だ。

プロダクトの品質を維持するためには変更のたびに回帰テストを行う必要がある。
手動テストですべての回帰テストを行っていると果てしないコストがかかるため、変更に関連していそうな一部のテストをやるのみというのが普通だろう。
しかし変更の影響が思わぬところで出てくるのがソフトウェア開発というものだ。

テストコードにより回帰テストが自動化されている場合は、完全な回帰テストのコストが低いため、コードは自然とよくテストされたコードになる。
思わぬ影響を完全に抑えられるとは限らないが、一部の回帰テストしかやっていない場合よりはそれを抑えられる可能性は高い。

回帰テストのコストが低くなると言うことは、つまりそれだけ変更のコストが低くなるし、変更自体にも強くなる。
このメリットはおそらくテストコードを書くコストのデメリットよりも大きい。

と、いろんなところで何度も書かれていそうなことを思考の整理がてら文章の落としてみた。
こうしてみるとTDDのメリットはやはり明らかなのだけれど、これを実際に浸透させるのはなぜか難しい。

なぜだろう？
とりあえずテスティングフレームワークの導入コストや適切なテストコードの書き方の学習コストなど、初期コストの高さはひとつの原因になっていそうだ。

それからそのせいもあって「理屈では分かっていても実感できるところまで行くのが難しい」ということもあるのかもしれない。