単体テストと統合テストのコードカバレッジレポートを個別に作成しますか、それとも両方のレポートを1つ作成しますか？
単体テストと統合テストの個別のコードカバレッジレポート、または両方のコードカバレッジレポートが必要ですか？
この背後にある考え方は、コードカバレッジにより、コードが可能な限りテストでカバーされていることを確認できるということです（とにかく、マシンができる限り）。
個別のレポートがあると、単体テストでカバーされなかったこと、統合テストでカバーされなかったことを知るのに便利です。しかし、この方法では、総カバレッジ率を確認できません。
何よりも、カバレッジの合計（合計）を取得して分析する必要があります。考えてみれば、これはリスクを適切に優先順位付けし、テスト開発作業に集中するための最も自然な方法です。
結合カバレッジは、どのコードがテストでカバーされていないかを示しますまったく、つまり、最もリスクが高く、最初に調査する必要があります。個別のカバレッジレポートは、コードが何らかの方法でテストされているかどうか、またはまったくテストされていないかどうかを確認できないため、ここでは役に立ちません。
個別のカバレッジ分析も役立つ場合がありますが、実行するほうがよい後複合分析が完了し、できれば、複合カバレッジの分析結果も含める必要があります。
個別のカバレッジ分析の目的は、結合されたものとは異なります。個別のカバレッジ分析は、テストスイートの設計を改善するのに役立ちます。これは、何に関係なく開発するテストを決定することを目的とした結合カバレッジの分析とは対照的です。
「ああ、この単純なユニット（統合）テストをユニット（統合）スイートに追加するのを忘れたからといって、このギャップはカバーされていません。追加してみましょう」-結合するとギャップを隠すことができるので、個別のカバレッジと分析が最も役立ちます。あなたが特定のスイートをカバーしたいと思うでしょう。
上記の観点からは、トリッキーなケースを分析するためにカバレッジ分析を組み合わせた結果も得られることが望ましいです。考えてみてください。これらの結果により、「パートナー」のテストスイートに関する情報があるため、テスト開発の決定がより効率的になる可能性があります。
「ここにはギャップがありますが、それをカバーするユニット（統合）テストを開発するのは本当に面倒です。選択肢は何ですか？結合カバレッジを確認してみましょう...すでに他の場所でカバーされています、つまり、私たちのスイートでそれをカバーすることはそれほど重要ではありません。」
テストツールについては言及しません。多くの場合、複数の実行またはスイートの結果を集約できる「結合」関数があります。集計カバレッジメトリックが必要な場合は、カバレッジツールの結合機能を調べてください。
さて、部屋の象について話してもいいですか？
スプーンはありません。また、「総カバー率」はありません。少なくとも、単純なものはありません。
カバレッジ率は、テストスイートの範囲、深さ、および範囲を理解するのに役立つように提示された、すぐに理解できるメトリックです。しかし、他の単純なベンチマークと同様に、「完全なテスト」の一種の魔法のようなお守りとして、この値を target fixated にするのは非常に簡単です。
「100％テストカバレッジ」の栄光を達成したとしましょう。 Yay！しかし、それはどういう意味ですか？コード行の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つに焦点を合わせています：私のソフトウェアシステムはどのくらい広範囲にテストされていますか？ 「いくつかのテストがあります」から「完全にテスト済み」への移行を支援します。
しかし、「複合スコア」で作業している間、実際には、スコアは通常、「条件」、「述語」、または「パス」カバレッジではなく、 「ステートメントカバレッジ」になります 。したがって、合計スコアがいくつあっても、プログラムの潜在的な状態と状態の組み合わせのどれだけがテストされているかを正確に示しているとは限りません。カバレッジ率の増加に取り組んでいる間、述語カバレッジの測定も検討してください。これにより、テストの拡張性について、より現実的な（そしてほとんどの場合、より落ち着いた）ビューが得られます。