web-dev-qa-db-ja.com

Java 8コードの条件付きカバレッジを測定することは意味がありますか？

Java 8が登場して以来、Javaの現在のツールによる条件付きコードカバレッジの測定は時代遅れではないのかと思います。 Java 8のOptionalおよびStreamを使用すると、コードの分岐/ループを回避できることが多く、すべての実行パスをテストすることなく非常に高い条件カバレッジを簡単に取得できます。古いJavaコードとJava 8コードを比較してみましょう。

Java 8以前：

public String getName(User user) {
    if (user != null) {
        if (user.getName() != null) {
            return user.getName();
        }
    }
    return "unknown";
}

上記の方法には、3つの実行パスがあります。条件付きカバレッジを100％取得するには、3つの単体テストを作成する必要があります。

Java 8：

public String getName(User user) {
    return Optional.ofNullable(user)
                   .map(User::getName)
                   .orElse("unknown");
}

この場合、ブランチは非表示であり、100％のカバレッジを得るために必要なテストは1つだけであり、どのケースをテストするかは問題ではありません。カバーする必要がある同じ3つの論理ブランチがまだあるとは思いますが、最近の条件付きカバレッジ統計は完全に信用できないと思います。

Java 8コードの条件付きカバレッジを測定することには意味がありますか？十分にテストされていないコードを見つける他のツールはありますか？

javaunit-testingtest-coveragejava8
19
Karol Lewandowski

Java 8で作成できる論理分岐を測定するツールはありますか？

私は何も知りません。念のため、JaCoCo（別名EclEmma）を使用してコードを実行してみましたが、Optionalバージョンでブランチが0と表示されています。私はそれを別の言い方で言うように構成する方法を知りません。 JDKファイルも含めるように構成した場合、理論的にはOptionalに分岐が表示されますが、JDKコードの検証を開始するのは馬鹿げていると思います。あなたはそれが正しいと仮定する必要があります。

しかし、中心的な問題は、Java 8の前に追加されたブランチが、ある意味で、人工的に作成されたブランチであったことを認識していることだと思います。それらはもはやJava 8は、ジョブに適切なツール（この場合はOptional）があることを意味します。Java8より前のコードでは、信頼できるように、追加の単体テストを作成する必要がありました。コードの各ブランチは許容できる方法で動作します。これは、User/getNameの例のように自明ではないコードのセクションで少し重要になります。

Java 8コードでは、代わりに、コードが適切に機能することをJDKに信頼しています。現状のまま、Optional行をコードカバレッジツールとして扱う必要があります扱います：ブランチが0の3行です。以下のコードに他の行とブランチがあることは、今まで注意を払っていなかったものですが、ArrayListのようなものを使用するたびに存在しますまたはHashMap。

4
Shaz