テストコードを書いていると、いつの間にかカバレッジの数字にこだわってしまいます。
「せっかくなら100%まで埋めよう」と思う気持ちは、私にもよく分かります。
結論から言うと、コードカバレッジは実務では70～80%台が最も現実的で、100%だからといってバグがないわけではありません。 私の経験も交えて、その理由を説明します。
まずは要点をまとめます
お忙しい方のために、この記事の結論を先にまとめます。
- カバレッジ100%は「すべての行が実行された」というだけで、「すべてのケースが検証された」わけではありません。
- 実務での推奨値は、おおむね70～80%です。
- 決済や認証のような重要なロジックは、90%以上を目指してもよいでしょう。
- 数字よりも、「何をテストしていないのか」を把握することが重要です。
コードカバレッジ100%ならバグはないのでしょうか？
最もよくある誤解がこれです。
カバレッジ100%とは、テストがコードのすべての行を「一度は実行した」という意味にすぎません。
その行が正しく動作することまで検証した、という意味ではありません。
例を見てみましょう。次の関数は、テストが実行するだけで結果を正しく確認していないケースです。
func divide(_ a: Double, _ b: Double) -> Double {
return a / b // bif 0なら？ テストは実行されますが
}
// このテストはカバレッジ 100%ですが
@Test func divide_実行するだけで_すませます() {
_ = divide(10, 2) // 戻り値を検証(#expect)しない!
}このコードはカバレッジ100%になります。
しかし、#expectで結果を確認していないため、実質的には何も保証しません。
カバレッジは「どれだけ実行したか」を測るものであり、「どれだけ適切に検証したか」を測るものではありません。
数字だけを見て安心してはいけない理由は、まさにここにあります。
では、何%が適切なのでしょうか？
複数のチームを経験して感じた現実的な基準を表にまとめました。（2026年時点で一般的な実務上の推奨値）
| コード領域 | 推奨カバレッジ | 理由 |
|---|---|---|
| コアビジネスロジック | 90%以上 | 決済・認証などは障害時の影響が大きい |
| 一般的なサービスコード | 70~80% | コストに対する効果が最も高い範囲 |
| UI・ビュー層 | 50~60% | 変更が多く、テストの維持コストが高い |
| 自動生成・設定ファイル | 測定対象外 | テストする意義が小さい |
Googleも、社内では60%を「受け入れ可能な水準」、75%を「推奨」、90%を「模範」と見なしていると公表したことがあります。
絶対的な正解はありませんが、多くのチームにとって80%前後が妥当な目標だと考えてください。
なぜ100%にこだわるとかえって損をするのでしょうか？
最後の20%を埋めるための努力は、最初の80%を埋めるよりはるかに大きくなります。
例外処理、到達しにくい分岐、防御コードまで全部テストすると、必要な時間は指数関数的に増えます。
さらに大きな問題があります。
数字を埋めるためだけに作られた「見せかけのテスト」が生まれることです。
実際には検証していないのにカバレッジだけを上げるテストは、後でコードを変更するときに足を引っ張ります。
リファクタリングのたびに、意味のないテストの修正に時間を使うことになります。
よくある質問（Q&A）
Q. では、カバレッジ測定自体に意味はないのでしょうか？
いいえ。カバレッジは「テストがまったく到達していない領域」を見つけるのに非常に役立ちます。
数字を目標にするのではなく、カバレッジレポートの赤い部分（未実行コード）を確認するために使いましょう。
Q. CIでカバレッジ基準を強制してもよいでしょうか？
設定しても構いませんが、「新規コードは80%以上」のような方法をおすすめします。
コード全体に一律で高い基準を設けると、既存コードのせいでチーム全体が疲弊します。
Q. カバレッジにはいくつか種類があるようですが？
行カバレッジだけでなく、ブランチカバレッジも一緒に見るとよいでしょう。
if/elseのような条件分岐が適切にテストされているかどうかのほうが、実際の品質に近いからです。
数字に追われず、「このテストは本当に何かを守っているのか」とまず問いかけてみてください。
カバレッジ80%の堅牢なテストは、100%の中身のないテストよりはるかに心強いものです。今日もよいテストコードを書けるよう応援しています！