コードカバレッジ分析のコードを除外する必要がありますか？

私はいくつかのアプリケーション、主にレガシーなものに取り組んでいます。現在、それらのコードカバレッジは非常に低く、通常は10〜50％です。

数週間以来、Cobertura（現在JaCoCoに移行している場合でも、コードカバレッジツール）のパッケージまたはクラスの除外について、バンガロールチームと頻繁に議論しています（開発の主な部分はインドのオフショアで行われます）。

彼らの視点は次のとおりです。アプリケーションの一部のレイヤーで単体テストを作成しないため（1）、これらのレイヤーはコードカバレッジ測定から単に除外する必要があります。言い換えれば、彼らはテストされているかテストされるべきコードにコードカバレッジ測定値を制限したいのです。

また、複雑なクラスの単体テストで作業する場合、その利点（純粋にコードカバレッジの観点から）は、大規模なアプリケーションでは見過ごされます。コードカバレッジの範囲を縮小すると、この種の作業がより明確になります...

このアプローチの興味は、テスト可能であると考えるアプリケーションの部分の現在の状態を示すコードカバレッジ測定を持つことです。

しかし、私の見解では、私たちは何らかの形で数字を偽造しています。このソリューションは、労力をかけずに、より高いレベルのコードカバレッジに到達する簡単な方法です。気になるもう1つの点は、ある週から別の週へのカバレッジの増加を示した場合、この良いニュースが開発者の良い仕事によるものなのか、単に新しい除外によるものなのかをどのように見分けることができますか？

さらに、コードカバレッジ測定で何が考慮されているかを正確に知ることはできません。たとえば、コード適用範囲が40％のコードアプリケーションが10,000行ある場合、コードベースの40％がテストされていると推定できます（2）。しかし、除外を設定するとどうなりますか？コードカバレッジが60％になった場合、正確に何を差し引くことができますか？「重要な」コードベースの60％がテストされていますか？どうやって

私が懸念している限りでは、「本当の」コードカバレッジ値を維持することを好みます。さらに、Sonarのおかげで、コードベースを簡単にナビゲートし、モジュール/パッケージ/クラスについて、独自のコードカバレッジを知ることができます。しかし、もちろん、グローバルなコードカバレッジはまだ低いでしょう。

その主題についてのあなたの意見は何ですか？あなたのプロジェクトはどうしますか？

ありがとう。

（1）これらのレイヤーは、一般的にUI / Java Beanなどに関連しています。

（2）それは真実ではないことを知っています。実際、それは私のコードベースの40％

通常、Visual Studioが生成するWCFクライアントなどの自動生成コードは除外します。通常、そこには多くのコード行があり、それらをテストすることは決してありません。これにより、他の場所のコードの大部分でのテストを増やし、コードカバレッジを0.1％だけ増やすことは非常に意気消沈します。

また、チームがこのレイヤーが可能な限り薄いことを確実に言うことができる限り、データレイヤーの相互作用も除外します。レイヤーが薄い場合、大きな影響はないと主張できますが、カバレッジレポートには多くのコンポーネントが0％で残っているため、必ずしも必要なものに気付かない本当に心配する。UIレイヤーは、使用されているフレームワークに応じて、同様の方法で議論できます。

しかし、対抗策として、単体テスト自体も除外します。常に〜100％のカバレッジが必要であり、コードベースの大部分を占めており、数字が危険なほど大きく歪んでいます。

良い質問。一般に、私はいくつかの理由でコードカバレッジからコードを除外する傾向があります。例えば：

• 生成された
• レガシー（もう更新されていません）
• ここに来る：特定の層、私はテストするつもりはない

なぜ最後のポイントですか？気を散らすのを抑えながら、気になっていることに集中することは良い習慣だと思います。UI層をテストするつもりがない場合、なぜそれを考慮に入れるのか-ソフトウェアの重要な部分-ビジネスロジックから注意を引くだけです。

だが：

1. ユニットテストから特定のレイヤーを除外する理由は十分にあるはずです（上司、チームメイト、マスコミからの質問があるかもしれません;-)
2. これらのレイヤーをテストする場合は、統計にそれらを含めて、重要であり、実行する必要があることを毎日チーム全体に示す必要があります。

最後に：数字を真剣に考えすぎないでください。30％のカバレッジは、ソフトウェアの重要な部分である場合に、ソフトウェアが堅実であることを証明する可能性があります。

私はあなたに同意する傾向があり、コードカバレッジメトリックに関連するすべてのコードを含めます（そして一般にSonar）。コードの一部をテストする予定がない場合（つまり、予見可能な将来）でも、メトリックは実際のステータスを反映する必要があります。これにより、コードベースの大部分のテストを作成しないという説得力のある理由が必要になります。最終的に（もう一方の、コードのより重要な部分がすでにカバーされている場合）、この不協和音を排除するために、再検討するか、別の方法を選択することができます。コードベースの異なる、テスト可能な部分、またはレイヤー全体を完全に削除することもできます（レイヤーにテストする価値がない場合、存在する十分な理由がありますか？）

現在のプロジェクトでは、1つの例外を除き、すべてのコードをメトリックに含めています。生成されたコードは、静的分析警告のヒープを生成します。このコードは通常、ロジックのない巨大なPODクラスで構成されているため、テストするものは何もありません。

今、私はあなたが使用しているコードカバレッジツールにあまり精通しておらず、Java Beanにも精通していません。

私の限られた知識で、私はこれを言っています：

1. あらゆる種類のテストツールの数字がテストを妨げないようにしてください。
2. クラスが複雑でユニットテストができない場合は、よりコンパクトでテスト可能なクラスにリファクタリングすることをお勧めします。それは多くの努力と献身を必要としますが、長期的には支払います。
3. UIコンポーネントのテストは難しい場合がありますが、それらのコンポーネントによって実行されている機能をテストすることはできます。
4. Webベースのプロジェクトを実行している場合、QUnitを使用してすべてのクライアント側コードを単体テストできます。

全体として、コードカバレッジは単なる数字であり、コードカバレッジが高いことは良いテストを示すものではないことに注意してください。より高い割合を目指すのではなく、コアライブラリをより堅牢でテストしやすくすることに焦点を当てます。

一部の除外は理にかなっています（実際に機能するプロジェクトに実際の影響や影響の可能性がないボイラープレートコード）。それでも、コードカバレッジをメトリックとして収集することは、とにかく有益なことを何も伝えないため、意味がありません。100％のコードカバレッジは実際の目標ではありません。また、プロジェクトによっては低いカバレッジ数でも悪くない場合があります。20-30％のコードカバレッジがテストに値するすべてをカバーする可能性があります。コードカバレッジは、実際にカバーする価値がある可能性があるコードのX％が、品質が不明な何らかのタイプのテストによるものであることを示しています。

コードの各レイヤーの一連のメトリックを報告することをお勧めします。これらのメトリックには、サイズ情報（LoC、ライブラリの数、クラスまたはメソッドの数など）、テスト情報（カバレッジなど）、およびバグ情報（率の検出と修正など）を含める必要があります。

除外されたレイヤーのカバレッジは0％になり、テストされたエリアのカバレッジは60％になります。サイズ情報により、テストされていないまたはテストされている量がわかります。除外されたレイヤーのテストを作成する必要があるかどうか、および既存のテストが機能しているかどうかは、バグ情報から通知されます。

ソフトウェア組織がメトリックの純度に集中しすぎることは簡単です。メトリックを作成するのではなく、優れたソフトウェアを作成します。高品質のソフトウェアをタイムリーに配信するのに役立つメトリックは、最も正直で純粋なメトリックです。