assert
テストでカバーされていないステートメントがあるため、Cobertura によって測定されたユニット テストのライン カバレッジに問題があります。イオンをテストする必要assert
がありますか? テスト範囲に影響を与えないように Cobertura にそれらを無視させる方法はありますか?
4 に答える
Javaステートメントのラインassert
カバレッジは、アサーションを有効にしてテスト スイートを実行する (つまり、jvm の引数として -ea を指定する) ことによって、単純にカバーする必要があります。これを行うと、cobertura が 100%のラインカバレッジを簡単に報告することがわかります (残りのラインもカバーされている場合)。
それにもかかわらず、assert
線はまだ赤く着色されており、不十分なカバレッジを示唆しています. これは、通常、アサーションが常に true であるため、false ブランチに到達することがないためです。
このように、Cobertura のブランチカバレッジは を使用すると台無しになりますassert
。なぜなら、assert 行は 50% のブランチ カバレッジを持ち、全体的なブランチ カバレッジのパーセンテージを解釈するのが困難 (または役に立たない) になるからです。
Cloverassert
には、カバレッジを計算するときに無視できる便利な機能があります。この機能は、オープン ソースの Java カバレッジ ツールでは見たことがありません。
契約による設計スタイルでアサーションを使用する場合、Javaassert
ステートメントを失敗させるテストを追加する必要はありません。実際のところ、多くのアサーション (不変条件、事後条件など) では、それらを失敗させるオブジェクトを作成することさえできないため、そのようなテストを作成することは不可能です。ただし、できることは、不変条件/事後条件を使用して、境界を実行するテスト ケースを導出することです。Robert Binderの不変境界パターンを参照してください。しかし、これでアサーションが失敗することはありません。
特定のメソッドに対して非常にトリッキーな前提条件がある場合にのみ、前提条件を失敗させることを目的としたテストを作成することを検討することをお勧めします。しかし、あなたの前提条件を再考することはより良い考えかもしれません.
アサート行を無視する機能を追加するために、Cobertura に対して既に記録されている機能要求 (1959691)があります。それが良い考えだと思う場合は、実装してページにコメントを追加する場合に備えて、気軽に見てください。assertステートメントは間違いなく良い考えだと思うので、オープンソースのカバレッジツールがまだこれをサポートしていないのは残念ですが、それらをテストすることは通常実用的/不可能です.
コード カバレッジは、テストを改善するためのツールであり、テストの有効性を証明するものではありません。100% のコード カバレッジを目指し、カバーされていないものを調べ、テストを改善する方法を検討することで、そこから価値を得ることができます。
カバーされていない assert ステートメントがあることを見つけることは、「わかりました、これをカバーする必要はありません」と呼ぶべき例にすぎません。これに似た例は、トレース マクロと、カバーされない隠し「if ステートメント」を追加するデバッグ コードです。
あなたの答えについてあなたが気に入らないのは、コードのコードカバレッジ要件を最小限にしたいということだと思います。私のプロジェクトのいくつかで同じ問題に直面しました。カバレッジ データを失ってはならない場合、解決策の 1 つは、問題のあるステートメント (アサート、トレースなど) を空のステートメント (マクロまたはリンカー マジックなど) に置き換える「カバレッジ ビルド」を行うことです。しかし、これは通常、完全ではないカバレッジを受け入れることのほうが良いトレードオフであると私は信じています.
幸運を。
おそらく、前提条件またはその他の条件のセットを検証するためにアサーションを使用しています。状況が引数に類似しているかどうかを検討してください。例外は単体テストする必要があります。
いずれにせよ、最終的には、これらのステートメントのネガティブパスブランチをテストする必要があるかどうかを判断しようとしていると思います。
はい、ぜひ、それらをテストしてください。あなたのアサーションはそれ自体があなたの仮定についての論理であり、あなたのガードステートメントがあなたがそうすると思うシナリオを防止/保護することをテストすることは良いことです。