Coverage(テストカバレッジ)とは
Coverage(テストカバレッジ)とは
定義と基本概念
Coverage(カバレッジ)とは、テストがソースコードのどの部分を実際に実行したか(到達したか)を定量的に示す指標です。
単に「テストがある」だけでなく、どこまで網羅されているかを可視化するための技術的手段として用いられます。
通常、次の4種のカバレッジ指標が測定されます:
種類 | 意味 |
---|---|
ステートメントカバレッジ | 文(命令)単位で実行されたか |
ブランチカバレッジ | if や switch の分岐がすべて網羅されたか |
関数カバレッジ | 各関数が呼び出されたか |
条件カバレッジ | 複数条件式(AND/OR)がすべての組み合わせで評価されたか |
Coverageの測定方法とツール
TypeScript / JavaScript
- Jest + Istanbul (nyc)
jest --coverage
→ HTMLやCLIで視覚化されたカバレッジレポートが得られる
Python
- pytest + coverage.py
coverage run -m pytest
coverage report
Go
go test -cover
go tool cover -html=coverage.out
その他(言語共通)
- Codecov(CIとの連携によるWebレポート)
- SonarQube(静的解析+カバレッジ統合)
なぜCoverageがレビューでも話題になるのか
テストが存在するだけでは“品質の裏付け”にならない
tests/ にファイルはある → でも全くコードに触れていない
Coverageを見ることで、「テストの有無」ではなく「テストの実効性」を測ることができます。
現場での使い方とレビュー観点
✔ カバレッジが基準を下回るとCIブロック
# Jestでの閾値設定例(package.json)
"coverageThreshold": {
"global": {
"branches": 80,
"functions": 85,
"lines": 90,
"statements": 90
}
}
✔ レビューコメントでの実例
Reviewer:
この部分、ifのelseブロックがカバレッジ0%です。
ロジック分岐の信頼性が弱いため、テスト追加検討してください。
カバレッジに関する誤解と注意点
カバレッジが高くてもバグは残る
- 「テストが当たっている」≠「正しくチェックされている」
- 観点が足りなければ、表面的に到達していても検証不足
過剰な100%要求は開発効率を下げる
- モックのためのモック、無意味なassertなどが増える
- 実務では80〜90%が現実的な落とし所(ただし重要部分は100%に近づける)
会話例:カバレッジをどう見るか
Reviewer:
coverage差分を見ましたが、auth関連のバリデーションが未テストですね。
login.test.ts に1ケース追加できると安心感あります。
Developer:
ありがとうございます、そちら追加して再Pushします。
まとめ:Coverageは「テストの深度を示す数字」
- テストカバレッジは可視化された信頼指標
- 過信せず、観点・設計と組み合わせて解釈することが重要
- CI連携やレビュー補助に活用することで、テスト品質を段階的に向上できる