先に要点
- カバレッジ(テストカバレッジ)とは、テストがソースコードのどれだけを実行したかを示す割合 です。`80%` なら、コードの8割がテスト中に1回でも通った、という意味です。
- 種類があり、行(命令)を見る C0、分岐を見る C1、条件の組み合わせを見る C2 の順に厳しくなります。ただ高ければよいわけではありません。
- 最大の落とし穴は カバレッジが高い = 品質が高い、ではない こと。アサーション(検証)が無くてもカバレッジは上がるため、`通っただけで何も確かめていない` テストでも数字は伸びます。
- 実務では 100%を目指すより、重要な箇所を厚く、全体で70〜80%前後を下げずに保つ 運用が現実的です。CI/CD で閾値を下回ったら失敗させる使い方が効きます。
テストカバレッジ80%を目標に カバレッジが下がったのでマージできない ── テストの話で必ず出てくるのがカバレッジです。便利な指標ですが、数字の意味を誤解すると カバレッジは高いのにバグが出る という状態に陥ります。
カバレッジとは、ひとことで言うと 「テストを実行したときに、ソースコードのどの部分が通ったかを測った割合」 です。テストがコードのどこを踏んでいて、どこを一度も踏んでいないかが分かるため、テストが薄い場所 を見つける地図として使えます。
この記事では、カバレッジの意味、種類(C0 / C1 / C2)、測り方、現実的な目標値、そして カバレッジ100%が品質を保証しない理由 と実務での付き合い方を整理します。
カバレッジとは何か
カバレッジは、テスト実行時に コードのどれだけが実行されたか を割合で表したものです。たとえば100行のうち80行がテスト中に通れば、行カバレッジは80%になります。
重要なのは、カバレッジが測っているのは 「実行されたかどうか」だけ という点です。実行された結果が正しいか までは見ていません。ここを取り違えると、後で説明する 100%の落とし穴 にはまります。
それでもカバレッジが役立つのは、「一度もテストされていない箇所」を確実に見つけられる からです。カバレッジが低い部分は、テストが手薄でバグが潜みやすい場所だと分かります。どこを優先的にテストすべきか の判断材料になります。
カバレッジの種類
カバレッジにはいくつかの粒度があり、見るものによって厳しさが変わります。代表的なものを整理します。
| 種類 | 何を見るか | 厳しさ |
|---|---|---|
| C0(命令/行網羅) | 各行(命令)が1回でも実行されたか | ゆるい。最もよく使われる基本指標 |
| C1(分岐網羅) | if の真・偽など、各分岐の両方を通ったか | 中。条件分岐のテスト漏れを拾える |
| C2(条件網羅) | 複合条件の各条件の真偽の組み合わせを通ったか | 厳しい。網羅すべき数が急増する |
| 関数カバレッジ | 各関数が1回でも呼ばれたか | ゆるい。呼ばれていない関数を発見できる |
たとえば if (a && b) という条件で、a も b も真 のケースしかテストしていない場合、C0(行)は通っていても、C1(分岐)では 偽になるケース が抜けていると分かります。C0 が高くても C1 が低いと、分岐のテストが甘い というサインです。
実務でまず見るのは行カバレッジ(C0)と分岐カバレッジ(C1)です。C2 まで厳密に追うのは、決済や安全性に関わるような特に重要なロジックに絞るのが現実的です。
カバレッジの測り方
カバレッジは専用のツールで自動計測します。多くのテストフレームワークに計測機能が組み込まれており、テスト実行時にオプションを付けるだけで出せます。
Vitest や Jest で計測オプションを付けて実行すると、行・分岐・関数の割合がレポートされる。内部では Istanbul という仕組みが使われることが多い。
pytest-cov や coverage.py を使う。どの行が通っていないかを一覧やHTMLレポートで確認できる。
JaCoCo が定番。ビルドに組み込み、しきい値を下回るとビルドを失敗させる運用がしやすい。
レポートの見方
全体の割合だけでなく、ファイル単位・行単位で `通っていない行` を見るのが大事。数字より、どこが手薄かを見る。
ポイントは、全体の%だけを見て一喜一憂しない ことです。カバレッジツールの本当の価値は、どのファイルのどの行がテストされていないか を具体的に示してくれるところにあります。レポートで赤くなっている行こそ、テストを足すべき場所です。
カバレッジ100%の落とし穴
カバレッジで最も誤解されやすいのが、「カバレッジが高い = 品質が高い」ではない という点です。
カバレッジは コードが実行されたか しか見ていません。そのため、結果を何も検証していない(アサーションが無い)テストでも、コードを通しさえすればカバレッジは上がります。極端な話、関数を呼ぶだけで何もチェックしないテストを書けば、カバレッジ100%でもバグは素通りします。
よくある誤解
`カバレッジ100%だからテストは完璧` は誤り。網羅率は `テストの量` の目安にはなるが、`テストの質` は保証しない。
数字合わせの弊害
100%を強制すると、`数字を上げるためだけの中身の無いテスト` が増えがち。逆に保守コストが上がる。
本当に見るべきもの
重要なロジック(計算・分岐・例外処理)に、`正しい結果かを検証するアサーション` があるか。カバレッジはその補助。
つまりカバレッジは 「テストされていない場所を見つける道具」として使い、「品質の証明」としては使わない のが正しい付き合い方です。数字を上げること ではなく、重要な箇所がちゃんと検証されていること を目的にします。
現実的な目標と運用
では実務でどう使うか。100%という数字を追うより、次の運用が効果的です。
特に有効なのが 差分カバレッジ(新しく変更した行のカバレッジ) を見る運用です。既存コード全体を一気に100%にするのは現実的でないことが多いので、新しく書く・変更する部分にはテストを伴わせる を基準にすると、無理なく全体の質が上がっていきます。
テストの種類ごとの役割を整理したい場合は、リリース直後の確認に使う スモークテストとは や、画面操作を通しで確認する Playwright(E2Eテスト) もあわせて読むと、カバレッジをどのテストで稼ぐかの見通しが立ちます。
CI/CD・TDDとの関係
カバレッジは CI/CD と組み合わせてこそ効きます。プルリクエストのたびに自動でカバレッジを計測し、下がっていたら警告・ブロックする ことで、テストの無いコードが少しずつ混ざるのを防げます。
TDD(テスト駆動開発)を実践している場合、カバレッジは自然と高くなります。先にテストを書いてから実装する ため、実装はテストに裏付けられた状態で生まれるからです。ただしこの場合も、カバレッジの数字そのものが目的ではなく、テストが設計の一部として機能していること が本質です。カバレッジはその結果としてついてくる、と捉えるのが健全です。
カバレッジに関するよくある質問
Q. カバレッジは何%を目標にすればいいですか？
A. 一律の正解はありませんが、全体で70〜80%前後を一つの目安にするケースが多いです。重要なのは絶対値より、重要な箇所が手厚くテストされているか と 下げない運用ができているか です。100%は費用対効果が悪くなりがちで、必須ではありません。
Q. カバレッジ100%なら品質は保証されますか？
A. されません。カバレッジは コードが実行されたか を見るだけで、結果が正しいか は見ていません。検証(アサーション)の無いテストでもカバレッジは上がるため、100%でもバグは素通りします。数字ではなく、重要な箇所が正しく検証されているかを見ます。
Q. C0・C1・C2 の違いは何ですか？
A. C0は各行(命令)が実行されたか、C1は分岐(ifの真偽など)の両方を通ったか、C2は複合条件の各条件の組み合わせを通ったかを見ます。C0からC2へ進むほど厳しくなり、網羅すべきケースも増えます。実務ではC0とC1を中心に見ます。
Q. 行カバレッジが高いのにバグが出るのはなぜですか？
A. 行カバレッジ(C0)は行を通ったかしか見ないため、分岐の片側しかテストしていなくても高く出ます。分岐カバレッジ(C1)を見ると、テストしていない条件が見つかることがあります。また、検証が甘いテストでも行カバレッジは上がるため、数字とバグは必ずしも反比例しません。
Q. どのツールで測ればいいですか？
A. 使っている言語のテストフレームワークに付属するもので十分です。JavaScript/TypeScriptならVitestやJest、Pythonならpytest-cov、JavaならJaCoCoが定番です。多くはテスト実行時にオプションを足すだけでレポートが出ます。
Q. 既存プロジェクトのカバレッジが低いです。どう上げますか？
A. 一気に全体を上げようとせず、差分カバレッジ(新しく変更した行)を基準にするのがおすすめです。新規・変更コードにはテストを伴わせるルールにすれば、触った場所から徐々に質が上がります。あわせて、壊れると影響が大きい重要なロジックから優先的に手を入れます。
Q. カバレッジとテストの数(件数)は同じ意味ですか？
A. 違います。テスト件数は テストをいくつ書いたか、カバレッジは コードのどれだけを通したか です。件数が多くても同じ場所ばかりテストしていればカバレッジは上がりませんし、逆に少ない件数で広く通すこともできます。両方を補助的に見ます。
Q. カバレッジをCIで強制すると何が起きますか？
A. しきい値を下回るとCIが失敗するため、テストの無いコードの混入を防げます。ただし厳しすぎると、数字を上げるためだけの中身の薄いテストが増える副作用があります。下げないを基準にした緩やかな閾値にするのが現実的です。
参考リンク
- Martin Fowler: Test Coverage
- Vitest: Coverage
- JaCoCo: 公式ドキュメント