bugfix> java > 投稿

私は最近、この非常に厄介な問題がどこからともなく出てきました。 EclEmmaカバレッジを有効にして単体テストを実行すると、Eclipseから次のダイアログウィンドウがポップアップ表示されます。

検索エンジンの場合、次のようになります。

No coverage data has been collected during this coverage Session.
Please do not terminate the Java process manually from Eclipse.

私のプロジェクトのどのクラスについても、カバレッジ情報は提供されていません。 言うまでもなく、私はJavaプロセスを手動で終了していません。それを修正するために私は:プロジェクトを再インポートし、Javaをアップグレードし、Emmaを再インストールし、Macbook Proを再起動し、一時ファイルシステムのスペースが適切であることを確認しました。その他20のことを今忘れています。

私はついに、このエラーを生成しているのは私のオープンソースプロジェクトのほんの2、3であることに気づき、私のテストの1つを絞り込むことにしました。これが問題を再現する最小のテストです。

私がカバーしようとしているテストクラス:

public class Foo {
    public void method() {
        System.out.println("hello");
    }
}

これを駆動するjunitクラスは次のとおりです。

public class EclEmmaFailureTest {
    @Test(timeout = 100000) // if you remove the timeout it works
    public void testStuff() {
        // this should cover Foo 100%
        new Foo().method();
        // if you comment this out stuff works
        org.apache.commons.logging.LogFactory.getLog(getClass());
    }
}

コモンズログ Log テストでの参照は、カバレッジコレクションを壊しているようです。私は次の場所に作業リポジトリを投稿しました:https://github.com/j256/eclemma-failure

次のいずれかを実行すると、問題は解決します。

  • コメントアウト LogFactory.getLog(getClass()) コール。
  • JUnitを削除します @Test タイムアウトフィールド。
  • JUnitを4.13.1から4.12にダウングレードします。

Emmaバージョン3.1.3を実行していますが、テストプログラムはcommons-loggingバージョン1.2に依存しています。

この問題を解決して再び作業できるようにするダウングレードパスがありますが、Junit4.12にはセキュリティの問題があります。これを引き起こしているjunitまたはemmaの特定の問題を誰かが知っているかどうか知りたいです。

Jacocoも影響を受けますが、これは驚くことではありません。これが私の報道レポートですJunit4.13.1にアップグレードする前 80%のカバレッジを示しており、ここにありますその後、カバレッジ情報なし 0%を表示して利用可能。

ありがとう。

回答 2 件
  • No coverage data has been collected during this coverage Session. Please do not terminate the Java process manually from Eclipse.

    これは、バージョン4.13で導入されたスレッドグループに関するJUnitの問題のようです。このgithubの説明と、このプルリクエストを参照してください。タイムアウトが設定されたとき、Junitはスタックスレッドの問題を処理するためにスレッドグループを破棄していたようで、Eclemmaにカバレッジ情報を書き出す機会を与えていませんでした。この問題を処理するためのより良い方法として、スレッドグループをデーモンスレッドに変更したようです。

    4.13.1より前のバージョンではセキュリティの問題が発生するため、唯一の解決策は4.13.2がリリースされるのを待たなければならないようです。

    Looks like shutdown hooks are not executed the same way in 4.13 as it used to happen in 4.12 and thus the coverage failure.

    これについて助けてくれたEclemmaメーリングリストに感謝します。

  • ここではEMMAは使用されていません、名前があってもEclEmmaそれを意味するかもしれません。実際、EclEmmaはEMMAのEclipse統合として2006年に開始されました。しかし、9年以上前、EclEmma 2.0以降、EMMAは、EclEmmaチームによって作成されたJava用の無料のコードカバレッジライブラリであるJaCoCoに置き換えられました。

    アプリケーションやテストでコードを変更すると問題が解決するため、カバレッジデータが収集されても表示されない可能性はほとんどありません。したがって、残っている可能性のある唯一の理由は何かがJaCoCoに干渉していますデータの収集。 JaCoCoのFAQは、それが何であるかを示しています。

    Why does a class show as not covered although it has been executed?

    First make sure execution data has been collected. For this select the Sessions link on the top right corner of the HTML report and check whether the class in question is listed. If it is listed but not linked the class at execution time is a different class file. Make sure you're using the exact same class file at runtime as for report generation. Note that some tools (e.g. EJB containers,mocking frameworks)might modify your class files at runtime. Please see the chapter aboutclass idsfor a detailed discussion.

    それがではないことを確認するにはキャッシュの問題、コードを少し変更するだけで問題が解決するかどうか試してみてください。

    問題を解決するためにリストしたものは非常に異なりますが、すべてがタイミングに影響を与える可能性があります。並行性の問題。テストの順序を変更したり、追加したりすることができます Thread.sleep() それが何かを変えるかどうか見るためにいくつかの場所で。

    しかし、あなたの場合、根本的な原因は不明です最小限の再現可能な例(並行性の問題である場合、提供するのは難しいかもしれません)。

    更新:

    結局のところ、根本的な問題は確かに並行性ですJUnit4.13.1の発行(以前のバージョンのJUnitは影響を受けません):

    JUnit 4の問題#1652:タイムアウトスレッドグループを破棄しないでください

    問題はすでにありました修繕今後のJUnit 4.13.2リリース。

あなたの答え