はじめに
「単体テストはテストカバレッジ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つを挙げられます。
1,変更頻度・今後のメンテナンス予定
2,影響範囲・ビジネスリスク
3,法規制・安全規格などの要求
順に見ていきます。
-
変更頻度・今後のメンテナンス予定
・よく変更が入るモジュール
・今後も機能追加が見込まれている箇所
こうした部分はバグが紛れ込みやすく、将来の影響も大きいため、
他より高めのカバレッジ（例：80〜90％） を目指す価値があります。
逆に、ほとんど触らないレガシー部分に無理やりテストを書くのは、
投資対効果が低いケースもあります。
-
影響範囲・ビジネスリスク
・課金・決済・認証・データ破壊につながる処理
・顧客への影響が大きい処理
このような箇所は、障害が起きたときのリスクが高いため、
・ブランチカバレッジや条件カバレッジを重視し
・85〜90％以上 を目標にするケースが多いです。
-
法規制・安全規格などの要求
・自動車・医療機器・産業機器などの分野では、
規格で「ブランチカバレッジ○○％以上」「MC/DC必須」などと定められる場合があります。
・この場合、プロジェクト独自の判断よりも、規格要求が優先されます。
カバレッジ目標の「一例」
あくまで一例ですが、現実的な運用イメージとしては次のような分け方があります。
・全体目標：
プロジェクト平均で ステートメントカバレッジ 70〜80％ 程度
・重要モジュール：
ビジネスロジック・安全上重要な部分は
ブランチカバレッジ 80〜90％
・周辺・補助的な処理：
ログ出力・UI・ラッパーなどは 60％程度でも許容
大事なのは、「なぜこの数字なのか？」をチームで合意しておくことです。
「なんとなく100％」ではなく、
リスク・コスト・納期のバランスで決められているか がポイントになります。
現場で使えるカバレッジ運用ルールの例
もう少し具体的に、チームで取り入れやすいルール例を挙げます。
・新規で書くコードは、原則 ステートメント 80％以上 を目指す
・既存レガシーコードは、「今回さわった範囲」だけ ブランチ 70〜80％以上を目標にする
・重要モジュールについては、「このファイルは80％以上」「このクラスは90％以上」などのリストを作っておく
・カバレッジが目標に届かない場合は、テストが極端に難しい、リスクが低く、投資対効果が薄いなどの理由をコメントや Wiki に残す
こうしておくことで、数字だけでなく背景も含めて判断できるようになります。
数値に振り回されず、“賢く”使う
カバレッジは、あくまで「テストが当たっていない場所を見つけるための道具」です。
・高いからといって、必ずしも高品質とは限らない
・低いからといって、必ずしも悪いテストとも限らない
重要なのは、
1,どの種類のカバレッジを
2,どのモジュールに対して
3,どの水準まで目指すのか
をチームで話し合い、「現実的に回せるライン」を決めて運用することです。
まとめ
・テストカバレッジ100％は「気持ちいい」指標ですが、コスト・設計・リスクのバランスを崩すこともあります。
・「どのコードに、どれくらい投資するか」を考え、変更頻度・リスク・規格要求を軸に “適切なカバレッジ” を決めるのがおすすめです。
・カバレッジは目的ではなく、議論と改善のきっかけになる指標として賢く使っていきましょう。