はじめに
「ちゃんと単体テストしたはずなのにバグが出た」という経験はありませんか？
本記事では、こうしたテストの抜け漏れが起きる根本原因と、それを防ぐための具体的な対策について解説します。
テスト項目表を一通り埋めて、
想定される入力パターンも確認したはずなのに、
なぜか現場で見つかってしまう不具合。
その背景には、多くの場合、単体テストという仕組み自体の“構造的な落とし穴”が潜んでいます。
本記事では、単体テストでバグが取りこぼされる主な原因と、
それに対して 何をすれば防げるのか を整理して解説します。
テストの抜け漏れが発生する4つの原因
-
条件・分岐の網羅性が足りていない
単体テストでは通常、関数やメソッド単位で動作を確認します。
しかし、実際のコードは if 文や switch 文など、分岐の組み合わせで複雑になりがちです。
if (user.isPremium() && purchaseAmount > 1000) {
applyDiscount();
}
このように複数条件が組み合わさった場合、
すべての条件の組み合わせ（条件網羅）をテストでカバーするのは簡単ではありません。
その結果、
・「プレミアムユーザーで、かつ購入額がちょうど閾値をまたぐとき」
・「特定フラグがオンかつ別条件がオフのとき」
といった “ごく一部の条件下だけで起きる不具合” が、
テストで検出されないままリリースされてしまいます。
-
テストケースが属人的で、漏れが発生する
多くの現場では、テストケースの作成が個人に依存しています。
その結果、
「実装者が自分のコードを、自分でテストする」
という構造になりがちです。
この場合、
・実装者の思い込みや前提条件がそのままテストに反映される
・異常系や境界値テストが、「たぶん大丈夫だろう」で抜け落ちる
といったリスクが高まります。
「書いた人の頭の中にある前提」＝「テストで検証される前提」
になってしまうと、そもそも“想定していないパターン”はテストに現れません。
-
テスト対象の粒度が適切でない
単体テストと言いつつ、実際には次のようなケースも少なくありません。
・関数が大きすぎて、複数の責務が混在している
・DBアクセスや外部API呼び出しを含んでおり、「純粋な単体テスト」になっていない
このような状況では、
・本来確認したいビジネスロジックが見えづらい
・テストコードも複雑になり、「どこを確認しているのか」が不明瞭
となり、結果として 検証漏れが起きやすくなります。
-
テスト支援ツールが導入されていない
テストの網羅性を 定量的に 把握するには、
・静的解析ツール
・カバレッジ測定ツール
といった支援ツールの活用が不可欠です。
しかし現場によっては、
・「コストがかかりそう」
・「学習コストが高そう」
といった理由で導入が進まず、
結果として 感覚頼みのテスト運用 になってしまっている例も少なくありません。
現場で起きたテストの抜け漏れ事例
ある金融系の計算モジュールで、
「休日をまたぐ場合の端数処理」に関する不具合が発生しました。
このモジュールには、本来 3 つの条件分岐が存在していました。
・通常稼働日
・休日をまたぐケース
・月末や締め日が絡むケース
しかし、実装者が作成したテストは 「通常稼働日」だけ を対象にしており、
祝日や月末などの特定条件下での挙動はテストされていませんでした。
その結果、
・実運用でそのパスが初めて実行されたタイミングでエラーが発生
・それまで一度も、その分岐が実行されていなかった
という、典型的な「網羅性不足による取りこぼし」が起きたのです。
テストの抜け漏れを防ぐ「可視化」と「自動化」
単体テストでの取りこぼしを減らすには、
人間の勘と根性に頼らない仕組み が必要です。
ポイントは、この2つです。
① 条件・分岐の“可視化”を行う
まずは、コードにどんな分岐が存在するのかを見える化することが重要です。
・ソースコードから制御フローグラフ（CFG）を生成する
・各分岐・条件がどのように連なっているかを俯瞰する
さらに、次のようなカバレッジ指標を測定することで、
テストの抜け漏れを客観的に評価できます。
・C0：命令網羅（ステートメントカバレッジ）
→ すべてのコード行が少なくとも一度は実行されたか
・C1：分岐網羅（ブランチカバレッジ）
→ if 文などで、true / false の両パスが実行されたか
・C2：条件網羅
→ 複数条件がある場合、それぞれの条件の true / false が組み合わせとして検証されているか
「どこまでテストできているのか？」を
数字と図で把握することが、網羅性向上の第一歩です。
② テストケースの“自動生成”を活用する
複雑な分岐を すべて人手で カバーしようとするのは、現実的ではありません。
そこで有効なのが、テストケース自動生成ツールの活用です。
・ソースコードの分岐条件から、機械的に入力値パターンを生成する
・条件網羅や分岐網羅を満たすテストケースを、自動的にリストアップする
これにより、
・「人が思いつかなかったパターン」が抜け落ちるリスクを削減
・テストケース設計の属人性を抑え、再現性の高いテスト運用が可能になります。
まとめ 〜“人の限界”を前提にしたテスト設計へ〜
単体テストでバグが取りこぼされる主な原因は、突き詰めると次の2点に集約されます。
・複雑な条件・分岐を「人間の頭だけ」で網羅しようとすること
・テストケース設計が属人的で、抜け漏れに気づく仕組みがないこと
だからこそ、
・条件・分岐の可視化（カバレッジの見える化）
・テストケースの自動生成（属人性の排除）
という 2 つのアプローチが重要になります。