Javaのprivateのテストについて書いていて思い出したので、カバレッジについて書いておく。
「カバレッジは100％でなくてもよい」という標語も、言葉が抜けているような気がするんだよね。
「カバレッジ」とひとことで言っても種類が色々あるらしいことは知っているのだが、自分はテストについて勉強しているわけではないので、種類まではよく知らない＾＾；
でも命令網羅・分岐網羅は100％になるべきだろう。
以前、HBase0.20のシェルでバグを踏んだことがあるけど、これなんかその部分を実行するテストをやっていれば（命令網羅100％ならば）、絶対発覚したはずのバグだし。
（もっと言えば、変数をちゃんと定義してコンパイルする言語で書かれていれば、（テストするまでもなく）コンパイルエラーになったはずなんだが）
プログラミング（コーディング）しているのに、その箇所を動かしていないというのは有り得ないよ(憤)
Javaの場合、テストできないのって、Cloneableに関するCloneNotSupportedExceptionをキャッチしている部分くらいのものだと思う。
switch文も、（コーディング規約によってdefaultを強制されている場合等は）実行されないケースがあるかもしれないけど。
もうひとつ、「カバレッジ」という語が指しているのが「自動テスト（JUnit）によるカバレッジ」ということなら、100％は難しいこともあるかもしれない。
例えば画面系のテストなんかは、自動テストは面倒だよね…。
「カバレッジは100％でなくてもよい」と言っている人は、どういう意図で言ってるだろうな？？
実際は最低限C0、C1くらいは100%にしておかないとバグバグで困るはずなんですけどね。でも、この手のメトリクスをとらない組織・人に限って上記発言をしそうで…。
ちなみにひしだまさんとご一緒したプロジェクトで、ひしだまさんの後輩が書いたであろう箇所でテスト未実行箇所であろう箇所で再現率100%でエラーになる箇所のデバッグをしたことがあります。ああいうのを見ると「テストしていないなぁ」「一度でも通しておけばこれくらい防げるのに」と思います。
そんなことも考えながら、
Mixer2というテンプレートエンジンを
作ってみました。
htmlタグをオブジェクトとして扱うので
テストを書くのも簡単です。
お暇なときにmixer2でググってみてください。