「単体テストはカバレッジ100％を目指すべきだ」
そんな会話を一度は聞いたことがあるかもしれません。
しかし、現場で限られた工数・納期の中で開発していると、
「100％を追いかけること」自体が目的化してしまい、本来守りたい品質がおろそかになることも少なくありません。
この記事では、
・カバレッジとはそもそも何か
・なぜ100％にこだわりすぎると危険なのか
・プロジェクトにとって“適切なカバレッジ”をどう決めるか
を整理してみます。
カバレッジとは？よく出てくる4種類
まずは用語の整理からです。
単体テストの世界で「カバレッジ」と言うとき、代表的には次のような種類があります。
・ステートメントカバレッジ
実行された「行」の割合
例）100行中80行がテストで実行された → 80％
・ブランチカバレッジ
if / switch などの分岐が、true/false ともに通ったか
条件分岐の抜け漏れを確認しやすい
・条件／判定カバレッジ（Condition / Decision）
if (A && B) のような複数条件の true/false 組み合わせを考慮したカバレッジ
分岐だけでなく、条件単位での網羅性を見る
・MC/DC（Modified Condition/Decision Coverage）
航空・自動車などの安全規格でよく要求される厳しめのカバレッジ
「各条件が、単独で判定結果に影響する」ことを確認する
カバレッジツールによってどこまで対応しているかは異なりますが、
「どの種類のカバレッジを、どのレベルまで求めるのか」が大事なポイントになります。
なぜ「100％」を目指したくなるのか
カバレッジは数値で見えるため、マネジメントしやすい指標です。
そのため、次のような流れで「100％」という目標が生まれがちです。
・数値で管理したい → カバレッジなら％で見えてわかりやすい
・「高いほど良いなら、100％が最高だよね」
・結果として「100％でない＝サボっている」という空気になる
気持ちはよく分かるのですが、ここにはいくつか落とし穴があります。
カバレッジ100％の落とし穴
- テストコストが膨らみすぎる
・初期化処理・ログ出力・デバッグ用コードなど、リスクが低い部分にまで時間をかけることになります。
・限られた時間を「本当にバグを埋め込みやすい箇所」に使えなくなる可能性があります。
- 「テストのためのコード」が増えすぎる
・100％を達成するためだけの不自然な分岐・設定を入れてしまう
・本来の設計よりも「カバレッジを上げやすい設計」を優先してしまう
結果的に、プロダクションコードの保守性が下がることもあります。
- 100％でもバグは残る
・カバレッジは「実行されたかどうか」であり、「正しく検証できているかどうか」までは保証してくれません。
・アサーションがないテストでも、ツール上はカバレッジが上がります。
・組み合わせ爆発や異常系まですべてカバーするのは、現実的ではありません。
「100％だから安心」ではなく、「どこをどのようにテストしたか」が重要です。
“適切なカバレッジ”を決める3つの視点
では、どのくらいを目標にすべきなのでしょうか。
万能の正解はありませんが、考えるうえでの軸を3つ挙げてみます。
- 変更頻度・今後のメンテナンス予定
・よく変更が入るモジュール
・今後も機能追加が見込まれている箇所
こうした部分はバグが紛れ込みやすく、将来の影響も大きいため、
他よりも高めのカバレッジ（例：80〜90％）を狙う価値があります。
逆に、ほとんど触らないレガシー部分に無理やりテストを書くのは、
投資対効果が低くなることもあります。
- 影響範囲・ビジネスリスク
・課金、決済、認証、データ破壊につながる処理
・顧客への影響が大きい処理
こうした部分は、障害が起きたときのリスクが高いため、
ブランチカバレッジや条件カバレッジを重視して、
85〜90％以上を目標にするケースが多いです。
- 法規制・安全規格などの要求
・自動車、医療機器、産業機器などの分野では、規格で「ブランチカバレッジ○○％以上」「MC/DC 必須」などと定められる場合があります。
・この場合、プロジェクト独自の判断よりも規格要求が優先されます。
カバレッジ目標の「例」
あくまで一例ですが、現実的な運用イメージとしては次のような分け方があります。
・全体目標：
プロジェクト平均で ステートメント 70〜80％程度
・重要モジュール：
ビジネスロジック・安全上重要な部分は ブランチ 80〜90％
・周辺・補助的な処理：
ログ・UI・一部のラッパーなどは 60％程度でも許容
大事なのは、「なぜその数字なのか」をチームで合意しておくことです。
「なんとなく100％」ではなく、リスク・コスト・納期のバランスで決められているかがポイントになります。
現場で使えるカバレッジ運用ルールの例
もう少し具体的に、チームで取り入れやすいルール例を挙げます。
・新規で書くコードは、原則 ステートメント 80％以上 を目指す
・すでにあるレガシーコードは、
「今回さわった範囲」は ブランチ 70〜80％以上 を目標にする
・重要モジュールについては、
別途「このファイルは80％以上」「このクラスは90％以上」などのリストを作る
・カバレッジが目標に届かない場合は、
なぜ届かないか（テストが難しい・価値が低いなど）をコメントやWikiに残す
こうしておくと、数字だけでなく背景も含めて判断しやすくなります。
数値に振り回されず、指標として“賢く”使う
カバレッジは、あくまで 「テストが当たっていない場所を見つけるための道具」 です。
・高いからといって、必ずしも高品質とは限らない
・低いからといって、必ずしも悪いテストとも限らない
大事なのは、
1.どの種類のカバレッジを
2.どのモジュールに対して
3.どの水準まで目指すのか
をチームで話し合い、「現実的に回せるライン」を決めて運用することです。
まとめ
・カバレッジ100％は「気持ちいい」指標ですが、
コスト・設計・リスクのバランスを崩すこともある。
・「どのコードにどれくらい投資するか」を考え、
変更頻度・リスク・規格要求を軸に“適切なカバレッジ”を決めるのがおすすめです。
・カバレッジは目的ではなく、議論のきっかけになる指標として活用しましょう。