Junit4: パラメータ化されたランナーを使用してクラスのテストのみを実行します

これを修正するのは素晴らしいことですが、大規模なテストクラスでUTにコメントする必要があり、これは望ましくありません。

Maven Surefireプラグインを使用すると、グロブを指定できます（http://maven.apache.org/surefire/maven-surefire-plugin/examples/single-test.htmlを参照）。 あなたはそれを試しましたか？

はい、それが私たちが使いたい方法ですが、それは機能しません。 これはsurefireプラグインの問題であり、junitの問題ではないと言っていますか？

@diogoeagSurefireプラグインの問題だと思います。 JUnitCoreを使用するmainメソッドを使用してクラスを記述し、 @Parameterizedを使用するクラスのテストを実行し、mainメソッドにフィルターを適用してテストの1つを選択させることで確認できます。

こんにちはケビン、

これらの2つのサンプルを見てください。

パラメータ化されていない最初のテスト：

package org;

import org.junit.Test;
import org.junit.internal.requests.FilterRequest;
import org.junit.runner.Description;
import org.junit.runner.JUnitCore;
import org.junit.runner.manipulation.Filter;

public class NoParameterTest {

    public static void main(String[] args) {
        new JUnitCore().run(FilterRequest.aClass(NoParameterTest.class).filterWith(new Filter() {
            <strong i="8">@Override</strong>
            public boolean shouldRun(Description description) {
                System.out.println("Should run test: classname[" + description.getClassName() + "] method name[" + description.getMethodName() + "]");
                return description != null && description.getMethodName() != null && description.getMethodName().equals("test");
            }

            <strong i="9">@Override</strong>
            public String describe() {
                return null;
            }
        }).getRunner());

    }

    <strong i="10">@Test</strong>
    public void test() {
        System.out.println("Running Test: test");
    }

    <strong i="11">@Test</strong>
    public void test2() {
        System.out.println("Running Test: test2");
    }
}

出力

Should run test: classname[org.NoParameterTest] method name[test]
Should run test: classname[org.NoParameterTest] method name[test2]
Running Test: test

パラメータ化された2番目のテスト：

package org;

import org.junit.Test;
import org.junit.internal.requests.FilterRequest;
import org.junit.runner.Description;
import org.junit.runner.JUnitCore;
import org.junit.runner.RunWith;
import org.junit.runner.manipulation.Filter;
import org.junit.runners.Parameterized;

import java.util.Arrays;
import java.util.Collection;

@RunWith(Parameterized.class)
public class ParameterTest {

    public static void main(String[] args) {
        new JUnitCore().run(FilterRequest.aClass(ParameterTest.class).filterWith(new Filter() {
            <strong i="18">@Override</strong>
            public boolean shouldRun(Description description) {
                System.out.println("Should run test: classname[" + description.getClassName() + "] method name[" + description.getMethodName() + "]");
                return description != null && description.getMethodName() != null && description.getMethodName().equals("test");
            }

            <strong i="19">@Override</strong>
            public String describe() {
                return null;
            }
        }).getRunner());

    }


    @Parameterized.Parameters
    public static Collection<Object[]> data() {
        return Arrays.asList(new Object[]{"Paramter 1"}, new Object[]{"Parameter 2"});
    }

    private String localParameter;

    public ParameterTest(String parameter) {

        this.localParameter = parameter;
    }

    <strong i="20">@Test</strong>
    public void test() {
        System.out.println("Running Test: test");
        System.out.println("Parameter: " + localParameter);
    }

    <strong i="21">@Test</strong>
    public void test2() {
        System.out.println("Running Test: test2");
        System.out.println("Parameter: " + localParameter);
    }
}

出力

Should run test: classname[[0]] method name[null]
Should run test: classname[[1]] method name[null]

パラメータ化によってフィルタに渡された説明が正しくありませんか？

@diogoeagコード例をありがとう。 どのバージョンのJUnitでこれを試しましたか？ 4.12で関連する問題を修正したと思いますが、よくわかりません。

@kcooney 、現在のマスター4.12-SNAPSHOTと4.11でテストしました。 どちらも同じ問題を抱えています。

ありがとう。 これを修正するには、下位互換性のない変更が必要です。 マイルストーンを5.0に設定

明確にするために、これを修正するには、BlockJUnit4ClassRunnerWithParametersに移動して、＃testNameメソッドのオーバーライドを削除するだけです。 それはデフォルトを置き換えています

    protected String testName(FrameworkMethod method) {
        return method.getName();
    }

に

    <strong i="9">@Override</strong>
    protected String testName(FrameworkMethod method) {
        return method.getName() + getName();
    }

そして、結果として、テストのレポートにはtestHeaderにパラメーター名が含まれません（少なくとも失敗したテストはこれらだけでした）？

@diogoeagですが、説明にパラメーター名を

修正は、JUnit5.0用に取り組んでいるDescriptionビルダーの上で行うのが最善だと思います。

@kcooneyはい、正解です。説明にパラメーター名を含める必要がありますが、説明がテスト名に影響を与えることはありません。 説明には、正しい名前である必要があるテスト名と、ユーザー向けの説明で使用する必要があり、パラメーターを含める必要がある表示名が必要であることに同意します。

5.0までの目標日についての見積もりはありますか？

getDisplayNameを使用して、修正を加えて5.0にプルリクエストを送信することを検討していましたが、プロジェクト（ソースとテスト）で23回使用されており、そのような変更を行うためのJUnitソースに関する十分な知識がありません。 その間、私は私のためにその中間修正で私の個人的な使用のためにフォークを作ります。 パラメータ名を持つことは重要ではありませんが、単一のテストを実行できるようにすることで、ソースでテストを実行する多くの開発者の時間を大幅に節約できます。

ありがとう

誰かがこの一時的な修正にアクセスする必要がある場合： https ：

@diogoeag
これを参照してください。 それはsurefire2.18に役立ちますか？
https://github.com/apache/maven-surefire/pull/46

@ Tibor17わかりません。 shoudlRunは説明も使用するためです。 私はそれが機能するかどうかを知るのに十分なコードベースを知りません。 それをテストするだけです。 私のサンプルコードは、修正のテストの1つになることもあります。 パラメータ化されたテストを使用すると、テスト名を変更するという問題があります。

@diogoeag
surefire MethodFilterでは、次のような条件を指定できるはずです。

String filterBy = JunitVersion < 5.0 & <strong i="7">@RunWith</strong> = Parameterized.class ? methodName + className : methodName

JUnitの問題を許容したい場合は、MavenSurefireプロジェクトで自分で修正プログラムをコミットできます。

@diogoeag JUnit 5.0の目標日はまだ

@kcooneyありがとう。 その間、内部リリースを使用します。

こんにちは、この問題はどうですか？ Parameterized.classを使用し、Mavenのsurefireを使用して単一のテストを実行する可能性がある回避策はありますか？ それとも、5.0バージョンを待つ必要がありますか？

@ Fanch-現在の修正はありません。 私たちが取り組んでいたImmutableDescriptionの作業でもこれを修正できると思いましたが、その努力は放棄されました。

とにかく冗長なので、 testName()からgetName()を削除しても大丈夫だと思います。

@ junit-team / junit-committersどう思いますか？

すべてのDescriptionインスタンスが、部分化されたテストに対して一意である限り。

説明に一意のIDを設定して、一意にすることができます。 しかし、サブツリー全体で一意である必要があるのか​​、なぜ必要なのか疑問に思っています。

はい、 Descriptionインスタンスは一意である必要があります。 テストの開始と終了を参照するためにリスナーに渡されるのはこれだけです。 示したようなツリーを構築し、テスト実行中に更新するには、どのテストが開始されたかを知る必要があります。

取られたポイント。 したがって、明示的な一意のIDを使用してテストの説明を作成する新しいファクトリメソッドをDescription追加する必要があると思います。 次に、現在の名前を一意のIDとして渡し、メソッドの名前だけを表示名として使用できます。 どう思いますか？

@marcphilipp説明には、指定された一意のIDでテストの説明を作成するためのメソッドがすでにあります： https ：

Descriptionが一意のIDを生成する必要があるとは思いません。 Parameterizedが決定論的値をDescription.createTestDescription()渡すことができません

説明には、指定された一意のIDでテストの説明を作成するためのメソッドがすでにあります： https ：

ええ、でもそれはクラスパラメータを持っていません。 したがって、別のものが必要です。

Descriptionが一意のIDを生成する必要があるとは思いません。 Parameterizedが決定論的値をDescription.createTestDescription()渡すことができません

私はそれを意味しませんでした。 つまり、 Parameterizedは一意のIDとしてmethod.getName() + getName()を、名前としてmethod.getName()を_pass_する必要があります。

SGTM。

JUnit 4の説明インスタンスを不変にするという考えを捨てましたが、静的な作成メソッドがあまり多くないようにビルダーを追加する必要がありますか？

もちろん！ 👍

いつ修正されるかについての見積もりはありますか？
このバグは、JUnit5の関連するバグをブロックします
https://github.com/junit-team/junit5/issues/549

@SqAutoTestTeam誰もこれに積極的に取り組んでいません。 私は最近、Description Builderブランチを更新したので、野心的な貢献者はそこから始めることができました。 または、さらに別の静的メソッドをDescription追加することもできます。

これを修正するには、Descriptionに新しいAPIが必要になります。 JUnit 5がこれらの新しいAPIを必要としないようにします（現在、JUnit5はほぼすべてのバージョンのJUnit4.xで動作します）

@diogoeag
この章をSurefireで読みましたか？
http://maven.apache.org/surefire/maven-surefire-plugin/examples/single-test.html#Multiple_Formats_in_One

パラメータ化されたテストのフィルタリングは、バージョン2.19以降で機能します。 あなたの場合、それは-Dtest=TesClass#testName[*]ではなく-Dtest=TesClass#testNameです。

@kcooneyと@marcphilipp 、

https://github.com/junit-team/junit5/pull/1018/files#diff -42ed8b618527eb1521dbe3cd9100e949R48の_fix_をJUnit4に「バックポート」することについてどう思いますか？

合理的な変更のように見える@sbrannen 。 これらの変更をバックポートした場合、JUnit4.13がJUnit5と互換​​性がなくなることや、JUnit4スタイルのテストを使用するプロジェクトでJUnit4スタイルのテストを実行する前に4.13にアップグレードする必要がないことを確認したいと思います。 JUnit5ランナーAPI。

@kcooney 、

それは合理的な変更のように見えます。

👍

これらの変更をバックポートした場合、JUnit4.13がJUnit5と互換​​性がなくなることや、JUnit4スタイルのテストを使用するプロジェクトでJUnit4スタイルのテストを実行する前に4.13にアップグレードする必要がないことを確認したいと思います。 JUnit5ランナーAPI。

JUnit 4では、変更はFilter#matchMethodDescription(Description) 1行のみになり、JUnit Vintageでも現在と同じ_fix_を維持できるため、 VintageTestEngineは引き続きJUnit4.12で機能します。 。

したがって、何かを見落としている場合を除いて、互換性の問題を回避する必要があります。

どう思いますか？

@sbrannen SGTM