あるチームは誇らしげに 95% のコード カバレッジを報告し、「カバーされた」行にバグを出荷します。これは矛盾ではありません。このカバレッジは、テストでこのコードが実行されたのかという 1 つの狭い質問に答えています。彼らが結果を確認したかどうかはまったく別の問題です。

Python では、coverage.py 7.17 と pytest 9.2 を使用しました。以下のすべての数値とレポートは、当社が独自に実行したものです。この考え方はどの言語にも当てはまります。

コードカバレッジとは何ですか?

コード カバレッジは、自動テストの実行中に実行されるコードの割合です。ツールは、どの行、およびオプションでどの分岐が実行されたかを記録し、何が欠落したかを報告します。

逆に使うと最も便利です。ある領域のカバー率が低いということは、テストがその領域を実行していないことを確実に示しています。カバレッジが高いと、得られる情報ははるかに少なくなります。

補償の種類

各レベルはその上のレベルよりも厳格です。ほとんどのチームはラインと支店のカバレッジを追跡しています。条件カバレッジと MC/DC は航空および自動車の規格に登場し、ツーリングのサポートが専門化されています。

測定したコード

def shipping_fee(total, is_member, express=False):
    if total < 0:
        raise ValueError("total cannot be negative")
    fee = 0 if total >= 1000 else 50
    if is_member:
        fee = max(fee - 25, 0)
    if express:
        fee += 100
    return fee

最初のテスト ファイルには 2 つのテストがありました。

def test_regular_order():
    assert shipping_fee(500, False) == 50

def test_member_express():
    assert shipping_fee(500, True, express=True) == 125

ブランチ測定をオンにして実行しました。

coverage run --branch -m pytest test_shipping.py
coverage report -m

レポートを読む

Name          Stmts   Miss Branch BrPart  Cover   Missing
---------------------------------------------------------
shipping.py       9      1      6      1    87%   3

• Stmts 9、Miss 1: 9 つの実行可能ステートメントのうち、1 つは実行されませんでした。
• 分岐 6、BrPart 1: 3 つの if 決定により、6 つの可能な結果が得られます。一つの決断は決して一方向にしか進まない。
• Missing 3: 行 3、raise ValueError は実行されませんでした。合計がマイナスのテストに合格しませんでした。

修正はエラー パスのテストです。また、大規模注文用のテストも追加しました。

def test_free_over_1000():
    assert shipping_fee(1000, False) == 0

def test_negative_total():
    with pytest.raises(ValueError):
        shipping_fee(-1, False)

どちらのファイルでも、レポートには 100% と表示され、欠落行や部分的な分岐はありませんでした。エラー パスは古典的なギャップ カバレッジの検出方法です。そのため、等価分割 などの手法で設計された無効な入力のテストが、エラー パスと非常によく組み合わされます。

報告書が隠したこと

もう一度最初のレポートを見てください。 3行目だけが欠落しているとのことでした。しかし、最初の 2 つのテストでは両方とも合計 500 個を使用したため、1,000 個以上の注文に対する送料無料ルールは 一度もテストされておらず、レポートでもフラグを立てていませんでした。

その理由は、fee = 0 if total >= 1000 else 50 が 1 行に収まっているためです。 coverage.py は行間の分岐を測定するため、単一行内の条件式は 1 つの実行されたステートメントとしてカウントされます。このルールにバグ (>= ではなく > など) があったとしても、最初のスイートはヒントなしで 87% を示していたでしょう。 境界値分析で説明されているように、境界自体のテストがそれを捕捉します。

チェックなしで 100% カバー

次に、すべてのパスを呼び出しますが、何もアサートしない、意図的に貧弱なテストを作成しました。

def test_runs_everything_but_checks_nothing():
    shipping_fee(500, True, express=True)
    shipping_fee(1000, False)
    shipping_fee(500, False)
    try:
        shipping_fee(-1, False)
    except ValueError:
        pass

shipping.py       9      0      6      0   100%

回線および支店のカバレッジが 100%に達しました。この関数は任意の数値を返すことができ、このテストは合格します。これはカバレッジの中核となる制限であり、検証ではなく実行を測定します。

テストが実際にバグを検出するかどうかを測定するには、突然変異テストを使用します。 Python の mutmut、Java の PIT、JavaScript の Stryker などのツールは、>= を > に反転するなどの小さな変更をコードに加え、テストが失敗するかどうかを確認します。私たちの非アサートテストでは、すべての突然変異が生き残ることになります。

どのような目標を設定するか

普遍的に正しい数字はありません。実践的なガイダンス:

• 100% を追求しないでください。 最後の数パーセントは、多くの場合、簡単なコードのテストや、行に触れるだけのテストの作成を意味します。
• 多くのチームは全体で約 70 ～ 85% を目指しており、コア ビジネス ロジックにはより高い期待が寄せられています。
• 数値ではなく、傾向に注目してください。 リリースごとにカバー率が低下している場合は、危険信号です。
• 古いコードを一度に強制的にアップするのではなく、プル リクエストで新しいコードのカバレッジを要求します。
• 明確なルールに従って、生成されたコードなど 重要でないものを除外します。

グッドハートの法則が適用されます。つまり、ある尺度が目標になると、それは良い尺度ではなくなります。ハード ターゲットは、アサートなしの例のようなテストを奨励します。

言語ごとのツール

CI の範囲

CI パイプラインの一部としてカバレッジを実行し、レポートを公開して、レビュー担当者がどの新しい行がテストされていないかを確認できるようにします。 coverage.py では、coverage report --fail-under=80 はしきい値を下回るとビルドに失敗します。しきい値は控えめに保ち、新しいコードのルールと組み合わせてください。これにより、単一の大きなレガシー ファイルによってすべての変更がブロックされることがなくなります。

対象範囲を超えて: 尋ねるべきより良い質問

• テストは、コードの危険な、頻繁に変更される部分をカバーしていますか?
• 幸せなパスだけでなく、境界とエラーパスもテストされていますか?
• この行が間違っていたらテストは失敗しますか?
• テストは変更のたびに実行できるほど高速で安定していますか?

これらは任意のテスト戦略に属します。カバレッジは最初の答えのみに役立ちます。

コードの除外と HTML レポートの読み取り

デバッグ ヘルパーやスクリプトが手動で開始された場合にのみ実行されるブロックなど、一部のコードは直接テストする価値がありません。 coverage.py を使用すると、コメントを含む行を除外できます。

if __name__ == "__main__":  # pragma: no cover
    main()

たとえば pyproject.toml のように、構成で除外対象と測定するソース フォルダーを設定することもできます。

[tool.coverage.run]
branch = true
source = ["shop"]

[tool.coverage.report]
show_missing = true
exclude_also = ["if TYPE_CHECKING:"]

除外は慎重に使用し、コードと同じように確認してください。それぞれは、一部の行は決してチェックされないという決定です。数値を上げるためだけにテストが難しいエラー ハンドラーを除外するのは、目的に反します。

日常的な作業では、ターミナル テーブルよりも HTML レポートの方が便利です。 coverage htmlを実行し、htmlcov/index.htmlを開きます。各ファイルは、実行された行が緑色、失敗した行が赤色、部分的な分岐が黄色で表示されるため、if が他のパスを選択しなかったことが一目でわかります。多くのエディターでは、マージンにカバレッジを表示することもできます。これにより、コードを書いた後ではなく、作成中にギャップが見えるようになります。

リファクタリング前のカバレッジ

カバレッジは、リファクタリング前の安全性チェックでもあります。モジュールを再構築する予定がある場合は、まずそのレポートを確認してください。赤い領域には動作が変化した場合に警告するテストがないため、開始する前に現在の動作を把握する特性評価テストを追加してください。このように使用すると、カバレッジは目標ではなくなり、実用的な計画ツールになります。

同じレポートは、バグが運用環境に漏れた場合に役立ちます。バグが存在する行を見つけて、テストでそのバグが実行されたかどうかを確認します。そうでない場合は、埋める価値のあるギャップを見つけたことになります。テストで実行された場合、問題は弱いアサーションであり、これはまさに、非アサートの例で示した状況です。どちらの答えも、スイートを改善する方法を示しています。

まとめ

コードカバレッジはグレードではなく懐中電灯です。ブランチ カバレッジを使用して、テストが触れていないコード (特にエラー処理) を見つけて、実際のアサーションを行うテストを作成します。実行結果の 1 つを覚えている場合は、次のようにしてください。何もチェックしないテストで 100% のカバレッジに達しました。

よくある質問

学び続ける