3秒でわかる
テストを流したときに、コードのうち何割が実際に実行されたかを示す指標。抜けている箇所を見つけるための地図として使います。
もう少し詳しく
どういうものか
カバレッジは、テストを1回走らせたあいだに、対象コードのどこが実行されたかを計測した割合です。測り方には段階があり、代表的なものは次の3つです。行カバレッジは実行された行の割合、分岐カバレッジは if の真と偽の両方を通ったかどうか、条件カバレッジは複合条件の各項目まで見ます。同じコードでも、行では100パーセントなのに分岐では50パーセント、ということが普通に起こります。
なぜ必要か
テストを書いていると、自分が意識した経路ばかり厚くなり、エラー処理や境界値が手つかずのまま残ります。カバレッジは、その「書いたつもりで触れていない場所」を機械的に指してくれます。人の記憶より正確で、レビューでも「この分岐は未テスト」と客観的に言えます。
具体例
Node.js のプロジェクトで測る例です。
npx jest --coverageFile | % Stmts | % Branch | Uncovered Line #s
----------|---------|----------|------------------
price.js | 100 | 50 | 12行はすべて通っているのに分岐が50パーセントなので、12行目の if が片側しか試されていないと分かります。
function shipping(total) {
if (total >= 5000) return 0; // ここだけ通っていた
return 500; // 未実行
}つまずきやすいところ
数字を目標にしてしまうのが最大の落とし穴です。カバレッジは「実行されたか」しか見ておらず、結果を検証したかは問いません。関数を呼ぶだけで assert を1つも書かないテストでも100パーセントは出ます。高いカバレッジは品質の証明ではなく、低いカバレッジが穴の証拠、という非対称な指標です。
自動生成コードや設定ファイルまで分母に入れて数字が下がり、無意味なテストを足して埋める、という動きもよく起きます。計測対象から外す設定を先に整えるほうが健全です。
もう1つの落とし穴は、行カバレッジだけを見て安心することです。三項演算子や短絡評価の || は1行に2つの経路を持つため、行としては通っていても片方は未実行、ということが起こります。数字を見るときは分岐のほうを先に読みます。
似た用語との違い
テストの網羅性を語る言葉としてホワイトボックステストとブラックボックステストがありますが、カバレッジは内部構造を見て測るのでホワイトボックス側の指標です。仕様から作る同値分割や境界値分析は、カバレッジでは測れない観点を補います。両方そろって初めて抜けが減ります。