【Python】テストカバレッジ100%の罠：分岐網羅だけでなく「条件網羅」で重要なロジックをテストしよう

2025年10月16日

「テストカバレッジ100%」という指標は、多くのプロジェクトで品質の一つの目標として掲げられます。すべてのコード行がテストで実行されたことを示すこの指標は、確かにテストが不足している箇所を見つけるのに役立ちます。しかし、カバレッジ100%が「バグがないこと」を保証するわけでは決してありません。

特に、if文などの条件分岐を単純に通過させるだけの**「分岐網羅（Branch Coverage）」**では、複雑な論理条件に潜むバグを見逃してしまう危険性があります。

今回は、より質の高いテストを目指すために、分岐網羅の一歩先を行く**「条件網羅（Condition Coverage）」**の考え方と、その重要性を解説します。

分岐網羅 vs 条件網羅

まず、2つのカバレッジレベルの違いを簡単な例で見てみましょう。

テスト対象のコード:

def can_enter_special_area(is_vip: bool, has_permission: bool) -> bool:
    # VIP会員 かつ 特別な権限を持っている場合のみアクセス可能
    return is_vip and has_permission

分岐網羅（不十分なテスト）: 「分岐網羅」は、if文（この場合はreturn文の条件）がTrueになるケースとFalseになるケースをそれぞれ最低1回ずつテストすれば達成できます。

# 'True'のケース
assert can_enter_special_area(is_vip=True, has_permission=True) is True
# 'False'のケース
assert can_enter_special_area(is_vip=False, has_permission=True) is False

この2つのテストで、分岐網羅率は100%になります。しかし、has_permission=Falseのケースが一度もテストされていません。もしand has_permissionの部分にバグがあっても、このテストスイートでは検出できません。

条件網羅（より網羅的なテスト）: 「条件網羅」は、is_vipとhas_permissionという、条件式を構成する個々の部分条件が、それぞれTrueとFalseの両方の値をとるようにテストケースを設計します。

# is_vip が True/False, has_permission が True/False を網羅
assert can_enter_special_area(is_vip=True, has_permission=True) is True
assert can_enter_special_area(is_vip=False, has_permission=True) is False
assert can_enter_special_area(is_vip=True, has_permission=False) is False
assert can_enter_special_area(is_vip=False, has_permission=False) is False

これにより、andで繋がれた条件のすべての組み合わせが検証され、テストの信頼性が格段に向上します。

実践例：分岐網羅だけでは見逃されるバグ

より現実的な、商品の検索機能を例に考えてみましょう。この関数は、検索語が「商品名」または「商品説明」のいずれかに含まれる場合に商品を返します。

テスト対象のコード (search.py):

from django.db.models import Q
from .models import Product

def find_products_by_term(term: str):
    # バグあり：descriptionの検索条件が誤っている (例: discription__icontains)
    query = Q(name__icontains=term) | Q(discription__icontains=term)
    return Product.objects.filter(query)

分岐網羅しか満たしていないテストスイート:

# tests/test_search.py
from .factories import ProductFactory

def test_find_by_name():
    """商品名で検索できることをテストする。"""
    product = ProductFactory(name="高性能スマートフォン")
    results = find_products_by_term("スマートフォン")
    assert product in results

def test_not_found():
    """無関係な商品はヒットしないことをテストする。"""
    ProductFactory(name="ワイヤレスイヤホン")
    results = find_products_by_term("スマートフォン")
    assert len(results) == 0

このテストスイートは、find_products_by_term関数を実行しており、カバレッジ上は問題なく見えます。しかし、検索条件の片方である**「商品説明での検索」を一度もテストしていません**。そのため、discription__icontainsという致命的なタイポを見逃してしまいます。

解決策：重要な「条件」を狙い撃ちするテストを追加する

このバグを発見するには、Q(...) | Q(...)というOR条件の、まだテストされていない側（商品説明での検索）を意図的に検証するテストケースを追加します。

条件網羅を意識した、より良いテストスイート:

# (test_find_by_name, test_not_found は上記と同じ)

def test_find_by_description():
    """商品説明で検索できることをテストする。"""
    product = ProductFactory(description="最新型スマートフォン。高画質カメラ搭載。")
    results = find_products_by_term("カメラ")
    assert product in results

このtest_find_by_descriptionを追加することで、Q(discription__icontains=term)のロジックが実行され、タイポによるエラーが発覚します。これにより、単にコードの行を実行するだけでなく、ロジックの各条件が正しく機能することを保証できるようになります。

pytestのparametrize機能を使えば、これらの条件をより体系的にテストすることも可能です。

@pytest.mark.parametrize(
    "product_attributes, search_term",
    [
        ({"name": "高性能スマートフォン"}, "スマートフォン"), # 条件1: 名前での検索
        ({"description": "高画質カメラ搭載"}, "カメラ"),   # 条件2: 説明での検索
    ]
)
def test_find_products_finds_matches(product_attributes, search_term):
    product = ProductFactory(**product_attributes)
    results = find_products_by_term(search_term)
    assert product in results

まとめ

テストカバレッジは便利な指標ですが、その数字だけを盲信するのは危険です。

カバレッジ100%は品質の出発点: カバレッジは「テストされていないコード」を教えてくれますが、「十分にテストされていること」は教えてくれません。
分岐網羅から条件網羅へ: 単にif文の分岐を通過させるだけでなく、andやorで構成される複雑な条件式については、その部分条件を一つずつ検証するテストケースを意識的に追加しましょう。
重要なロジックを特定する: すべてのコードで条件網羅を目指すのは非現実的です。アプリケーションのコアとなる、最も重要で複雑なビジネスロジックを特定し、そこに対して重点的に詳細なテストを書くことが費用対効果の高いアプローチです。

テストの真の目的は、自信を持ってコードをリリースし、変更し続けられるようにすることです。そのためには、カバレッジという「量」だけでなく、テストの「質」にも目を向けることが不可欠です。

よかったらシェアしてね！