コードカバレッジ分析からコードを除外する必要がありますか？
主にレガシーアプリケーションなど、いくつかのアプリケーションに取り組んでいます。現在、それらのコードカバレッジは非常に低く、一般に10〜50％です。
数週間以来、Cobertura（現在JaCoCoに移行している場合でも、コードカバレッジツール）のパッケージまたはクラスの除外に関して、バンガロールチーム（開発の主要部分はインドのオフショアで行われます）と繰り返し議論しています。
彼らの視点は次のとおりです。彼らはアプリケーションの一部の層でユニットテストを作成しない（1）なので、これらの層は単にコードカバレッジメジャーから除外する必要があります。つまり、コードカバレッジ測定をテスト済みまたはテスト済みのコードに制限したいと考えています。
また、複雑なクラスの単体テストに取り組んでいる場合、大規模なアプリケーションでは、純粋にコードカバレッジの観点から、その利点が気付かれることはありません。コードカバレッジの範囲を縮小すると、この種の取り組みがより見やすくなります...
このアプローチの興味深い点は、アプリケーションの一部の現在のステータスをtestableとして示すコードカバレッジメジャーを用意することです。
しかし、私の考えでは、数字をどうにか偽造しているということです。このソリューションは、手間をかけずにコードカバレッジのレベルを上げる簡単な方法です。気になるもう1つの点は次のとおりです。ある週から別の週にカバレッジが増加した場合、この良いニュースが開発者の優れた成果によるものか、単に新しい除外によるものかをどのように判断できますか？
また、コードカバレッジメジャーで考慮される内容を正確に知ることはできません。たとえば、コードカバレッジが40％のコードアプリケーションが10,000行ある場合、コードベースの40％がテストされたことを差し引くことができます（2）。しかし、除外を設定するとどうなりますか？コードカバレッジが60％になった場合、正確に何を差し引くことができますか？ 「重要な」コードベースの60％がテストされていますか？どうやって
私に関する限り、私たちはそれについて明るくできなくても、「実際の」コードカバレッジ値を維持することを好みます。さらに、Sonarのおかげで、コードベース内を簡単に移動して、モジュール/パッケージ/クラスについて、独自のコードカバレッジを知ることができます。しかし、もちろん、グローバルなコードカバレッジはまだ低いでしょう。
そのテーマについてのあなたの意見は何ですか？プロジェクトでどのようにしていますか？
ありがとう。
（1）これらのレイヤーは一般的にUIに関連しています/ Java beansなど）.
（2）私はそれが真実ではないことを知っています。実際、コードベースの40％が
通常、Visual Studioが生成するWCFクライアントなどの自動生成コードは除外します。通常、そこには多くのコード行があり、それらをテストすることは決してありません。これにより、他の場所で大量のコードのテストを増やし、コードカバレッジを0.1％だけ増やすことは非常に意気消沈します。
また、このレイヤーが可能な限り薄いとチームが確信を持って言える限り、データレイヤーの相互作用も除外します。レイヤーが薄い場合、それは大きな影響を及ぼさないと主張できますが、カバレッジレポートには多くのコンポーネントが0％で残されるため、必要なコンポーネントに必ずしも気づかない場合があります。本当に心配する。使用されているフレームワークに応じて、UIレイヤーも同様に議論できます。
ただし、対置として、単体テスト自体も除外します。それらは常に〜100％のカバレッジを持つ必要があり、それらはコードベースの大きなパーセンテージになり、数値を危険なほど上方に歪めます。
良い質問。一般的に、私はいくつかの理由でコードカバレッジからコードを除外する傾向があります。それは：
- 生成された
- レガシー（もう更新されません）
- ここに来る：特定のレイヤー、テストするつもりはない
なぜ最後のポイントですか？気晴らしを抑えながら、気になることに集中するのは良い習慣だと思います。 UIレイヤーをテストするつもりがない場合は、なぜそれを考慮に入れる必要があります。これは、ソフトウェアの重要な部分（ビジネスロジック）から注意を引くだけです。
だが：
- 特定のレイヤーを単体テストからまったく除外するのには十分な理由があるはずです（上司、チームメイト、マスコミからの質問があるかもしれません;-)
- これらのレイヤーをテストする場合は、それらを統計に含めて、チーム全体を示す必要があります。毎日、それが重要であり、実行する必要があることを示します。
最後に：数値をあまり深刻にしないでください。 30％のカバレッジは、ソフトウェアが不可欠な部分である場合、ソフトウェアが堅実であることを証明する可能性があります。
私はあなたに同意する傾向があり、すべての関連コードをコードカバレッジメトリック（およびソナー一般）に含めます。コードの一部をテストする予定がない場合でも（予測可能な将来のために）、メトリックは実際のステータスを反映する必要があります。これにより、コードベースの大部分のテストを記述しないという説得力のある理由が必要になります。最終的に（コードの他のより重要な部分がすでにカバーされている場合）、再検討するか、この不協和を解消する別の方法を選択することができます。問題のコードをリファクタリングしてテスト可能にしたり、すべてのロジックをコードからコードベースの別のテスト可能な部分に移行したり、レイヤー全体を完全に削除したりします（レイヤーにテストする価値がない場合は、存在する十分な理由？）
現在のプロジェクトでは、メトリックにすべてのコードを含めていますが、例外が1つあります。生成されたコードで、静的分析警告のヒープが生成されます。このコードは通常、ロジックのない膨大なPODクラスで構成されているため、テストする必要はありません。
今、私はあなたが使用しているコードカバレッジツールにあまり詳しくなく、Java Beansにも精通していませんが、UIに関連していると言っています。
私の限られた知識で、私はこれを言う必要があります：
- あらゆる種類のテストツールによる数値がテストの妨げにならないようにしてください。
- クラスが複雑でユニットテストができない場合は、クラスをよりコンパクトでテスト可能なクラスにリファクタリングすることを常にお勧めします。それは多くの努力と献身を必要とするでしょうが、それは長期的には支払うでしょう。
- UIコンポーネントのテストは難しい場合がありますが、それらのコンポーネントによって実行されている機能をテストすることもできます。
- Webベースのプロジェクトを実行している場合は、QUnitを使用してすべてのクライアント側コードを単体テストできます。
全体として、コードカバレッジは単なる数値であり、高いコードカバレッジは優れたテストを示すものではないことに注意してください。より高いパーセンテージを目指すのではなく、コアライブラリをより堅牢でテスト可能なものにすることに焦点を当てます。
一部の除外は意味があります（プロジェクトに実際に影響を与えない、またはプロジェクトに影響を与える可能性のない定型コード）。それでもとにかく有用なことを何も教えてくれないので、メトリックとしてコードカバレッジを収集しても意味がありません。 100％のコードカバレッジは実際の目標ではなく、低いカバレッジ数もプロジェクトによっては悪くない場合があります。20-30％のコードカバレッジはテストに値するすべてのものをカバーする可能性があります。コードカバレッジは、実際にカバーする価値がある可能性のあるコードのX％が、未知の品質のある種のテストによるものであることのみを通知します。
コードの各レイヤーのメトリックのセットを報告することをお勧めします。これらのメトリックには、サイズ情報（LoC、ライブラリの数、クラスまたはメソッドの数など）、テスト情報（カバレッジなど）、およびバグ情報（検索率と修正率など）を含める必要があります。
除外したレイヤーのカバレッジは0％になり、テストしたエリアのカバレッジは60％になります。サイズ情報は、テストされていないかテストされている量を人々に理解させるでしょう。除外されたレイヤーのテストを作成する必要があるかどうか、および既存のテストが機能しているかどうかは、バグ情報で通知されます。
ソフトウェア組織にとって、メトリックの純粋さにあまりにも集中するのは簡単です。指標は作成しません。優れたソフトウェアを作成します。高品質のソフトウェアをタイムリーに提供するのに役立つメトリックは、最も正直で純粋なメトリックです。