ひがやすを技術ブログ

電通国際情報サービスのプログラマ

テストを書くときはコストベネフィットを考えろ

InfoQにKent Beckの最新の提案がでてますね。Kent Beck氏、ごく短期のプロジェクトではテストを省略することを提案


でも、これは、Kent Beckが「ごく短期のプロジェクトではテストを省略しても良い」といってるわけではないと思うんですよ。キャッチーなタイトルをたまたまつけられてしまっただけで。


重要なポイントはここだと思います。

Maxを開発しているとき、テストを書くか否かという質問は、要するに、そのテストが単位時間当たりにより多くの有効な実験をするのに役立つかどうかでした。もし役に立つのであれば、私はテストを書きます。そうでなければ、不要だと判断します。私はMaxの収入を軌道に乗せるためのチャンスを最大化しようとしているのです。

つまり、「テストがかけた時間の割りに役に立つと思ったら書くし、そうでなければ書かない」ということだと思います。別に短期のプロジェクトでも、コストベネフィットが大きければ、テストを書いたほうがいいということです。


KentがMaxの開発の初期に、テストを書かなかったのは、MaxはEclipseのPluginであり、EclipseのPluginはテストしづらいということが、根本にあったと思います。テストを書くのにコストがかかるから、コストベネフィットが小さいと判断してテストを書かなかったわけです。


TDDをやっていると、テストを書くことが面白くて、ついテストに時間をかけてしまいがちですが、コストベネフィットを考えてテストを書くかどうか決めるのは、とても重要なポイントだと思います。


テストを書くことが目的ではない。最終的に利益につながるなら、テストをうまく利用するということです。


追記:経済屋さんからすれば、「費用対効果が高い」とかいう言い方は間違いということなので、コストベネフィットという言い方に変えます。間違った使い方でごめんなさい。