計算方法¶カバレッジはこうやって出すんですよという資料を書いていたら自分がわかっていなかったので調べた話です。カバレッジを取得した場合、その値はいくつになるでしょう。オプションは無効の状態で取得するものとします。自体を調べたことある人以外間違えるのでは無いかと思います。値から算出しているとみて良いでしょう。ドキュメントを読む必要があります。よるとファイルごとに実行された「行」を記録しているファイルに対して実行可能な行を取得している。実行可能な行から除外している。(つまりバイトコード)が保持している行番号のテーブルを参照しているということのようです。Coverage)を出してるんですねこれ。実行されなかった行のリストを表します。実行可能ではない扱いになっているがわかります。それ自体に処理があるわけではないので集計対象にならないようです(ネットで見た感じなので要出典)。実際のところ網羅率について目標設定するのはあまり意味がないように思います。どれだけ重要なロジックが含まれるかは数値から読み取れません。誰かが頑張って割合を上げた分、誰かが怠けられるようになるだけなようにも思えます。個人的には網羅率は気にせずテスト漏れ(Missing)の検出器として使うのが良いのではないかと思います。あったら直すという感じですね。coverあるいは重要なパッケージの置き場所を決めておいて、そこだけカバレッジを出すなど行っていけば、そこまでコストがかかることも無いかと思います。テストを考慮していない実装に対して新たにカバレッジ測定ツールを導入して100%まで持っていくのは当然辛いので、コストというのはそこから来ているんじゃ無いかという気もしますが。信用ならないと書いてありますが、これは数値だけ見てテストを書いた結果意図が読み取れないテストになっている疑いがあるっていう話で、まぁやっぱり「(見落としていた)テストが不十分なコードを見つける」のに有用なわけですね。テストしなくてもよい(10%~20%の)コードはそう分かるようにマーク等で除外しておけば、毎回集計結果を見て「あれここテストしなくていいんだっけ?と確認せずに済むので良いのではというのが上記の意図するところで、その結果数値は100%になりますが、それを目標にしようというわけではないです。実際問題としてフレームワーク的な制約でうまく除外するのが難しいという可能性はありますが。網羅率の概念の説明から実演という流れが綺麗にできるのでは?」と思い実際にやってみた結果、よくわからない数値が出てきたというが発端でした。オプションが有効な場合、行数に分岐数を加算するような実装になっているので、理論値(?)とは合わないようです。最初の目的からするとそこは残念でしたが、バイトコードを使うという発想は素晴らしいなと思いました。Coverage)で計算してるものと勝手に思っていた。把握していないが他にもきっとある。