単体テストと統合テストのコードカバレッジレポートを分けますか、それとも両方のレポートを1つにしますか？

単体テストと統合テストの個別のコードカバレッジレポート、または両方のコードカバレッジレポートが必要ですか？

この背後にある考え方は、コードカバレッジにより、コードが可能な限りテストによってカバーされていることを確認できるということです（とにかく、マシンができる限り）。

個別のレポートがあると、単体テストでカバーされなかったこと、統合テストでカバーされなかったことを知るのに便利です。しかし、この方法では、総カバレッジ率を確認できません。

何よりも、（合計）カバレッジを組み合わせて分析する必要があります。考えてみれば、これはリスクを適切に優先順位付けし、テスト開発の取り組みに集中するための最も自然な方法です。

結合カバレッジは、どのコードがテストでまったくカバーされないかを示します。つまり、最もリスクが高く、最初に調査する必要があります。個別のカバレッジレポートは、コードが何らかの方法でテストされているかどうか、またはまったくテストされていないかどうかを確認できないため、ここでは役に立ちません。

個別のカバレッジ分析も役立つ場合がありますが、複合分析が完了した後で行う方がよいでしょう。できれば、複合カバレッジを分析した結果も含めるのが望ましいでしょう。

個別のカバレッジ分析の目的は、結合されたものとは異なります。個別のカバレッジ分析は、テストパッケージの設計を改善するのに役立ちます。これは、開発するテストを決定することを目的とする結合カバレッジの分析とは対照的です。

「ああ、この単純なユニット（統合）テストをユニット（統合）スイートに追加するのを忘れたため、このギャップはカバーされていません。追加してみましょう」あなたが特定のスイートをカバーしたいと思うでしょう。

上記の観点から、トリッキーなケースを分析するために、カバレッジ分析を組み合わせた結果も得られることが望ましいです。考えてみてください。これらの結果により、「パートナー」のテストスイートに関する情報があるため、テスト開発の決定がより効率的になる可能性があります。

「ここにはギャップがありますが、それをカバーするユニット（統合）テストを開発することは本当に面倒です。オプションは何ですか？結合カバレッジを確認しましょう...ああ、それはすでに他の場所でカバーされています。非常に重要です。」

テストツールについては言及しません。多くの場合、複数の実行またはスイートの結果を集約できる「結合」関数があります。集計カバレッジメトリックが必要な場合は、カバレッジツールの結合機能を調べてください。

さて、部屋の象について話してもいいですか？

スプーンはありません。また、「総カバー率」はありません。少なくとも、単純なものはありません。

カバレッジパーセンテージは、テストスイートの範囲、深さ、および範囲を理解するのに役立つように提示された、すぐに理解できるメトリックです。しかし、他の単純なベンチマークと同様に、「完全なテスト」の一種の魔法のお守りとして、この値に固執するターゲットになることは非常に簡単です。

「100％テストカバレッジ」の栄光を達成したとしましょう。わーい！しかし、それはどういう意味ですか？コード行の100％がテストされていますよね？次に、この行はどうですか？

launch_missile = launch_authorized and launch_cmd_given else previous_launch_status

その行を「カバーする」ことは何かを意味します- ある確率で、TrueまたはFalseある確率でさまざまな条件があるので、全体ではありませんが、それらの条件のすべての組み合わせをテストしたことはほとんどありません。その行が数十回カバーされたとしても、条件の1つが比較的珍しい場合、実際に発生する可能性のある実際の結果のすべてをテストすることに近づいていません。それをより明確にするために、より総合的な例：

engage_laser = (laser_armed and safety_disengaged) or random.random() < 0.0000003

本当に徹底的にテストするには、その行を何回カバーする必要がありますか？プログラム内の他のすべての変数と組み合わせてテストするために何回カバーする必要がありますか？

カバレッジ指標が役に立たないと言っているのではありません。彼らは実際に素晴らしいです。彼らは重要な問題の1つに焦点を合わせています：私のソフトウェアシステムはどのくらい広範囲にテストされていますか？「いくつかのテストがあります」から「完全にテスト済み」への移行を支援します。

ただし、「複合スコア」で作業している場合、実際のスコアは通常、「条件」、「述語」、または「パス」カバレッジではなく「ステートメントカバレッジ」になります。したがって、合計スコアがいくつあっても、プログラムの潜在的な状態と状態の組み合わせがどの程度テストされているかを正確に把握しているとは限りません。カバレッジパーセンテージの増加に取り組んでいる間、述語カバレッジの測定も検討してください。これにより、テストの拡張性について、より現実的な（そしてほとんどの場合、より落ち着いた）ビューが得られます。