なひです。
なひは、カバレジ100%でないテストは犯罪、という観点から、
XPのUTにおいてカバレジは常に100%であるべき、という立場です。
> From: Eiji Yamane [mailto:e-yamane@....jp]
> Sent: Wednesday, July 31, 2002 1:25 AM
> あと、実際テストファーストでやっていれば、自ずとカバレッジは
> 上がってくるでしょうしね。
同感です。
# 以下は、個人的にはテストファーストしないなひが
# 言うことかどうかわかりませんが。^^;
XP的には、基本的には常に100%になる、ということなんじゃ
ないでしょうか。テストファーストで実装した以上、
実装にテストでカバーできない部分があったら、
YAGNIにひっかかるんじゃないでしょうか。
> 「遵守」すべきは、テストファーストであって、その「結果」である、
> 「カバレッジ」は個人的には目くじら立てなくても、
> 「おぉ、やっぱテストファーストはえぇわぁ！」
> と実感する程度の認識でいたほうが気楽でええんじゃないかなぁと・・・
「XPのプラクティス（の一部）を『遵守』できているかどうか」
を測る指針として考えるとどうでしょうか。
カバレジはよい指針になりそうな気がしませんか。
/ / /
上で「基本的に100%」と書きましたが、いくつか難しい
部分もあって。。。最近の言語においては、例外のthrowも
カバレジを取るべきパスの一つですが、
RuntimeExceptionをどれだけ効率的に、どこまで追うか、
で最近悩んでいます。
public class Foo {
public double rateFor100(int i) {
return 100/i;
}
private static void testRateFor100() {
Foo obj = new Foo();
assert(obj.rateFor100(5) == 20.0);
}
public static void main(String[] arg) {
testRateFor100();
}
}
例えばこんな例ですが、メソッドrateFor100には、
i == 0を渡された場合にArithmeticExceptionを投げるという
パスがあります。テストファースト時に、
ソフトウェアテスト工学的によく訓練されたテスターの
帽子をかぶっていれば、この程度のパスは事前に予想して
テストが書けると思います。とはいえ、同じRuntimeExceptionでも、
Java特有のCastErrorExceptionなんかは、実装を見るまでは
予想しきれないことも多いでしょう。そうすると、
UTではカバーできない、実装により織り込まれたパスが
でてくることになります。
こういうパスが残りうる以上、
結局（少なくともなひ要件からは）カバレジは取らざるを
得なくなります。まだ各種カバレジツールを評価中なのですが、
この手の暗黙のパスを見つけてくれそうなカバレジツールは
少なそうな予感がしています。
結局、よいテスターが頑張る、しかないのかなぁ。