山根です。
こんばんは。
品質わるわるコードを大量生産している僕が発言するのも
おこがましいですが、ちょっとだけ、オブジェクションです。
＃単なる茶々とも言います。f(^_^;
On Tue, 30 Jul 2002 09:53:47 +0900
石井 勝 <ishii036@....jp> wrote:
> 菊池さん，こんにちは．石井です．
>
> > そうですね。カバレッジはあくまで指標だと考えています。
> > 但し、最低限クリアすべき指標であると考えます。
>
> 実践してないのになんですが^^;，そうだと思います．
こう言ってしまうと、やっぱりカバレッジは最低限満たしていなければ
ならない、当然の作業のように聞こえてしまいます。
現実問題、テストカバレッジ率云々で品質を確保するのは、
大昔から言われたことであって、昨今言われ始めたものでは
ないと思います。
問題なのは、
・なぜ、カバレッジ（のみ）で品質が上がらないか？
・なぜ、カバレッジを今更ながら叫ぶのか？
の２点だと思うんです。
前者は、まぁいろいろな方の発言通り、それだけでは品質はカバーできないし、
後者は、やっぱ台所事情とかで、多少犠牲にされちゃったりするわけですね。
理想はともかく。
だから今、この不況の世の中大事なのは、
「効率の良い高品質を導けるテストおよび設計」では無いかと思います。
そのいくつかのテーゼとして、
シンプルデザインだったり、テストファーストがあったりするわけで、
ここで、カバレッジを導入してしまうと、
・カバレッジ率が低い＝品質が悪い
・カバレッジ率が高い＝品質が良い
と言う安易な等式をでっち上げられるのが怖いです。
多分どちらも「かもしれない」と文末につく程度です。
「かもしれない」を手に入れるだけのお金と工数が残っていれば、
その保険を取るために、カバレージ向上を行っても良いかとは思います。
あと、実際テストファーストでやっていれば、自ずとカバレッジは
上がってくるでしょうしね。
「遵守」すべきは、テストファーストであって、その「結果」である、
「カバレッジ」は個人的には目くじら立てなくても、
「おぉ、やっぱテストファーストはえぇわぁ！」
と実感する程度の認識でいたほうが気楽でええんじゃないかなぁと・・・
別に否定しているわけではなく、テストファーストで作られたコードは、
ある程度カバレッジ率も高いし、それ以上カバレッジ率を上げるのは、
コスト対効果的に美味しくないんじゃないかと思った次第です。
誰も納得はしてくれませんが、ピンク本の
「『失敗するかもしれない全てのこと』をテストする」
が、一プログラマーとしては最も大切な心構えだと思います。
> ユニットテストを書いていて一番困るのがテストコードのメンテナンスの問題
> です．何ヶ月も経っていたり，別の人が書いていたりすると，テストコードが
> 本当に必要かどうかわからなくなるんですよね．一体これは何のためのテスト
> か，と．そういうときにカバレッジツールがあると不要なテストコードを消し
> ていいかどうかの重要な判断材料になりそうです．
これは、ありですね。
時間がたつと同じパスで違うバリエーションのテストを複数行っていたり
しまうからね。f(^_^;
> あと，恐怖のビッグリファクタリングでも大活躍しそうですね．
こっちは、逆もありきで、
メソッドベースの試験をMockオブジェクト使って実施していると、
ビッグリファクターの後始末がかなり大変だったりします。
＃C#見たいに、オーバーライド表明できれば、
＃コンパイルレベルで発見されるのでもうちょっと楽なんでしょうけど・・・
> カバレッジの専門的な話はまったく知らないですが，コードが実行されたかど
> うかだけではなく，必要なテストデータを網羅しているか，という話も当然あ
> りそうです．コードの実行とテストデータの完全性を参照できる指標があれば
> いいですね．
こちらの方がより重要ですね。
ただ、今のところ経験則に頼っている面が多いのが実情でしょうけど。f(^_^;
山根 英次（Eiji Yamane)
mailto:e-yamane@....com
http://www.ne.jp/asahi/e/yamane/software/