私はJacocoで100％テストカバレッジを目指すべきですか？

Question

私は現在、プロジェクトのテストカバレッジを向上させるために取り組んでいます。それは約93％で、私は100％に向かって作業しています。

私がカバーされていないブロックの一つは、メインメソッドであることに気付き、それは次のようになります。アプリケーションは、90以上のテストを持っており、@SpringBootTest注釈といくつかのにもかかわらず

public static void main(String[] args) { 
    SpringApplication.run(Application.class, args); 
} 

、このメインメソッドはまだカバーされていません。

私はこれについて心配し、100％カバレッジを取得する必要がありますか？あるいは、私は完璧主義者でありすぎて、のものは、上記の例のようにをテストする価値がないのですか？

上記のコードがテストで実行されていないのはなぜですか？それを実行するためにmainメソッドを明示的に呼び出す必要がありますか？アプリケーションの起動時に呼び出されることを期待していました。

Answer 1

私は100％を目指すべきですか？はい、いつも！。しかし、90％以上のものは良いと言われています。すべてのシナリオで100％達成することは不可能かもしれません。

春の起動アプリケーションの起動に使用されているだけで、機能をカバーしていないため、メインメソッドを含むクラスをpom.xmlファイルのカバレッジから除外できますプロパティタグ内のコードの次の行：

<sonar.coverage.exclusions> 
    **/com/example/test/MainApplication.java 
</sonar.coverage.exclusions> 

Answer 2

あなたはそれを楽しむためにユニットテストをしません。したがって、あなたはまた別の目的のためにカバレッジを見ます。

目的は、必要な品質を持つソフトウェアを構築することです。可能な限り、物事を測定したり目標を設定したりすることはありませんが、そうするプロセスは製品の品​​質向上に役立ちます。

したがって、このようなコードのテストの追加価値を明確に定義できる場合は、ここで時間を費やす価値があります。特にこれに費やす時間が他のものには使えないエネルギーのためです。

あなたのチームの人々と一緒に座って、そのようなテスト（そして100％カバレッジのような目標を超えて）の投資収益率を評価し、その結果に従ってください。言い換えれば、あなた自身の優先順位を決めるために、見知らぬ人からの助言を見たくない（あまりにも）。あなたはあなたの製品を知っています、私たちはしません。

Answer 3

私は100％テストカバレッジ[...]を目指すべきですか？

はい。

しかし、ではなく、のコード行が含まれますが、の要件が必要です。

あなたの自動テスト（ユニットテスト、モジュールのテストと受け入れテスト）は、プロジェクトのドキュメントで修正された要件の100％をカバーする必要があります。

これを実現する最善の方法は、テスト駆動型開発です。

TDDは100％のカバレッジにつながりませんが、測定可能なテストカバレッジの一定量としてはるかに価値のある信頼性の高いセーフティネットを作成します。

Answer 4

コードカバレッジ自体によっては無用メトリックあります。あなたのコード/要件がどのようにカバーされているかは教えていません。完全にカバーされていない場所だけを指し示すことができます。実際に何もチェックしない恐ろしいテストで100％に達するのはとても簡単です。

さらに、メトリクスに晒されている人は、改善のためにできることは何でも行います。便利なことを行うのではなく、これらのメトリクスを導入した後、（少なくとも私の練習では）人々は、より悪いカバレッジでより悪いテストを書き始めます（私はここでラインカバレッジについて話していません）。

テストの質に本当に関心がある場合は、コードレビューを行う必要があります。メトリクスが好きで、ライン/ブランチカバレッジに固執したい場合は、少なくとも突然変異テストも導入してください。

最終的には、いいえ、ラインやブランチのカバレッジの100％に達するようにしないでください。