コードカバレッジ分析のコードを除外する必要がありますか？
私はいくつかのアプリケーション、主にレガシーなものに取り組んでいます。現在、それらのコードカバレッジは非常に低く、通常は10〜50％です。 数週間以来、Cobertura（現在JaCoCoに移行している場合でも、コードカバレッジツール）のパッケージまたはクラスの除外について、バンガロールチームと頻繁に議論しています（開発の主な部分はインドのオフショアで行われます）。 彼らの視点は次のとおりです。アプリケーションの一部のレイヤーで単体テストを作成しないため（1）、これらのレイヤーはコードカバレッジ測定から単に除外する必要があります。言い換えれば、彼らはテストされているかテストされるべきコードにコードカバレッジ測定値を制限したいのです。 また、複雑なクラスの単体テストで作業する場合、その利点（純粋にコードカバレッジの観点から）は、大規模なアプリケーションでは見過ごされます。コードカバレッジの範囲を縮小すると、この種の作業がより明確になります... このアプローチの興味は、テスト可能であると考えるアプリケーションの部分の現在の状態を示すコードカバレッジ測定を持つことです。 しかし、私の見解では、私たちは何らかの形で数字を偽造しています。このソリューションは、労力をかけずに、より高いレベルのコードカバレッジに到達する簡単な方法です。気になるもう1つの点は、ある週から別の週へのカバレッジの増加を示した場合、この良いニュースが開発者の良い仕事によるものなのか、単に新しい除外によるものなのかをどのように見分けることができますか？ さらに、コードカバレッジ測定で何が考慮されているかを正確に知ることはできません。たとえば、コード適用範囲が40％のコードアプリケーションが10,000行ある場合、コードベースの40％がテストされていると推定できます（2）。しかし、除外を設定するとどうなりますか？コードカバレッジが60％になった場合、正確に何を差し引くことができますか？「重要な」コードベースの60％がテストされていますか？どうやって 私が懸念している限りでは、「本当の」コードカバレッジ値を維持することを好みます。さらに、Sonarのおかげで、コードベースを簡単にナビゲートし、モジュール/パッケージ/クラスについて、独自のコードカバレッジを知ることができます。しかし、もちろん、グローバルなコードカバレッジはまだ低いでしょう。 その主題についてのあなたの意見は何ですか？あなたのプロジェクトはどうしますか？ ありがとう。 （1）これらのレイヤーは、一般的にUI / Java Beanなどに関連しています。 （2）それは真実ではないことを知っています。実際、それは私のコードベースの40％