Wie werden Testmethoden in einer bestimmten Reihenfolge in JUnit4 ausgeführt?

Ich möchte Testmethoden ausführen, die @Testin einer bestimmten Reihenfolge mit Anmerkungen versehen sind .

Zum Beispiel:

public class MyTest {
    @Test public void test1(){}
    @Test public void test2(){}
}

Ich möchte sicherstellen, dass es test1()vor test2()jedem Start ausgeführt MyTestwird, konnte jedoch keine Anmerkungen wie finden @Test(order=xx).

Ich denke , es ist ganz wichtiges Merkmal für JUnit, wenn Autor von JUnit nicht die will , um Funktion , warum?

Ich denke, es ist eine ziemlich wichtige Funktion für JUnit. Wenn der Autor von JUnit die Bestellfunktion nicht möchte, warum?

Ich bin mir nicht sicher, ob es einen sauberen Weg gibt, dies mit JUnit zu tun. Meines Wissens geht JUnit davon aus, dass alle Tests in einer beliebigen Reihenfolge durchgeführt werden können. Aus den FAQ:

Wie verwende ich ein Testgerät?

(...) Die Reihenfolge der Aufrufe von Testmethoden kann nicht garantiert werden , daher kann testOneItemCollection () vor testEmptyCollection () ausgeführt werden. (...)

Wieso ist es so? Nun, ich glaube, dass es eine Praxis ist, die Autoren nicht fördern wollen, die Reihenfolge der Tests abhängig zu machen. Tests sollten unabhängig sein, sie sollten nicht gekoppelt sein und Verstöße gegen diese Bestimmungen erschweren die Wartung, beeinträchtigen die Fähigkeit, Tests (offensichtlich) einzeln durchzuführen usw.

Wenn Sie jedoch wirklich in diese Richtung gehen möchten, sollten Sie TestNG in Betracht ziehen, da es das Ausführen von Testmethoden in beliebiger Reihenfolge unterstützt (und Dinge wie die Angabe dieser Methoden hängen von Gruppen von Methoden ab). Cedric Beust erklärt, wie dies in der Reihenfolge der Ausführung von Tests in testng zu tun ist .

Wenn Sie Ihre vorhandene Junit-Instanz entfernen und JUnit 4.11 oder höher im Erstellungspfad herunterladen , führt der folgende Code die Testmethoden in der Reihenfolge ihrer Namen aus, sortiert in aufsteigender Reihenfolge:

@FixMethodOrder(MethodSorters.NAME_ASCENDING)
public class SampleTest {

    @Test
    public void testAcreate() {
        System.out.println("first");
    }
    @Test
    public void testBupdate() {
        System.out.println("second");
    }
    @Test
    public void testCdelete() {
        System.out.println("third");
    }
}

Wenn die Bestellung wichtig ist, sollten Sie die Bestellung selbst aufgeben.

@Test public void test1() { ... }
@Test public void test2() { test1(); ... }

Insbesondere sollten Sie bei Bedarf einige oder alle möglichen zu testenden Auftragspermutationen auflisten.

Zum Beispiel,

void test1(); 
void test2(); 
void test3(); 


@Test
public void testOrder1() { test1(); test3(); }

@Test(expected = Exception.class)
public void testOrder2() { test2(); test3(); test1(); }

@Test(expected = NullPointerException.class)
public void testOrder3() { test3(); test1(); test2(); }

Oder ein vollständiger Test aller Permutationen:

@Test
public void testAllOrders() {
    for (Object[] sample: permute(1, 2, 3)) {
        for (Object index: sample) {
            switch (((Integer) index).intValue()) {
                case 1: test1(); break; 
                case 2: test2(); break; 
                case 3: test3(); break; 
            }
        }
    }
}

Hier permute()ist eine einfache Funktion, die alle möglichen Permuationen in eine Sammlung von Arrays iteriert.

Die Migration zu TestNG scheint der beste Weg zu sein, aber ich sehe hier keine klare Lösung für jUnit. Hier ist die am besten lesbare Lösung / Formatierung, die ich für jUnit gefunden habe:

@FixMethodOrder(MethodSorters.NAME_ASCENDING)
public class SampleTest {
    @Test
    void stage1_prepareAndTest(){};

    @Test
    void stage2_checkSomething(){};

    @Test
    void stage2_checkSomethingElse(){};

    @Test
    void stage3_thisDependsOnStage2(){};

    @Test
    void callTimeDoesntMatter(){}
}

Dies stellt sicher, dass Stage2-Methoden nach Stage1-Methoden und vor Stage3-Methoden aufgerufen werden.

Es ist eines der Hauptprobleme, mit denen ich bei der Arbeit an Junit konfrontiert war, und ich habe folgende Lösung gefunden, die für mich gut funktioniert:

import java.util.ArrayList;
import java.util.Collections;
import java.util.Comparator;
import java.util.List;

import org.junit.runners.BlockJUnit4ClassRunner;
import org.junit.runners.model.FrameworkMethod;
import org.junit.runners.model.InitializationError;

public class OrderedRunner extends BlockJUnit4ClassRunner {

    public OrderedRunner(Class<?> clazz) throws InitializationError {
        super(clazz);
    }

    @Override
    protected List<FrameworkMethod> computeTestMethods() {
        List<FrameworkMethod> list = super.computeTestMethods();
        List<FrameworkMethod> copy = new ArrayList<FrameworkMethod>(list);
        Collections.sort(copy, new Comparator<FrameworkMethod>() {

            @Override
            public int compare(FrameworkMethod f1, FrameworkMethod f2) {
                Order o1 = f1.getAnnotation(Order.class);
                Order o2 = f2.getAnnotation(Order.class);

                if (o1 == null || o2 == null) {
                    return -1;
                }

                return o1.order() - o2.order();
            }
        });
        return copy;
    }
}

Erstellen Sie auch eine Schnittstelle wie unten:

 @Retention(RetentionPolicy.RUNTIME)


@Target({ ElementType.METHOD})

public @interface Order {
public int order();
}

Angenommen, Sie haben Klasse A, in der Sie mehrere Testfälle wie die folgenden geschrieben haben:

(@runWith=OrderRunner.class)
Class A{
@Test
@Order(order = 1)

void method(){

//do something

}

}

Die Ausführung beginnt also mit der Methode "method ()". Vielen Dank!

Mit JUnit können Testmethoden derzeit die Reihenfolge mithilfe von Klassenanmerkungen ausführen:

@FixMethodOrder(MethodSorters.NAME_ASCENDING)
@FixMethodOrder(MethodSorters.JVM)
@FixMethodOrder(MethodSorters.DEFAULT)

Standardmäßig werden Testmethoden in alphabetischer Reihenfolge ausgeführt. Um die Reihenfolge bestimmter Methoden festzulegen, können Sie sie wie folgt benennen:

a_TestWorkUnit_WithCertainState_ShouldDoSomething b_TestWorkUnit_WithCertainState_ShouldDoSomething c_TestWorkUnit_WithCertainState_ShouldDoSomething

Beispiele finden Sie hier .

Die (noch nicht veröffentlichte) Änderung https://github.com/junit-team/junit/pull/386 führt a ein @SortMethodsWith. https://github.com/junit-team/junit/pull/293 machte zumindest die Reihenfolge ohne diese vorhersehbar (in Java 7 kann es ziemlich zufällig sein).

Sehen Sie sich einen JUnit-Bericht an. JUnit ist bereits nach Paketen organisiert. Jedes Paket hat (oder kann) TestSuite-Klassen, von denen jede wiederum mehrere Testfälle ausführt. Jeder TestCase kann mehrere Testmethoden des Formulars haben public void test*(), von denen jede tatsächlich eine Instanz der TestCase-Klasse wird, zu der sie gehören. Jede Testmethode (TestCase-Instanz) hat einen Namen und ein Bestanden / Nicht Bestanden-Kriterium.

Was mein Management benötigt, ist das Konzept einzelner TestStep- Elemente, von denen jedes seine eigenen Bestanden / Nicht Bestanden- Kriterien angibt . Das Fehlschlagen eines Testschritts darf die Ausführung nachfolgender Testschritte nicht verhindern.

In der Vergangenheit haben Testentwickler in meiner Position TestCase-Klassen in Paketen organisiert, die den Teilen des zu testenden Produkts entsprechen, eine TestCase-Klasse für jeden Test erstellt und jede Testmethode zu einem separaten "Schritt" im Test gemacht. komplett mit eigenen Pass / Fail-Kriterien in der JUnit-Ausgabe. Jeder TestCase ist ein eigenständiger "Test", aber die einzelnen Methoden oder Testschritte innerhalb des TestCase müssen in einer bestimmten Reihenfolge ausgeführt werden.

Die TestCase-Methoden waren die Schritte des TestCase, und Testdesigner erhielten pro Testschritt ein separates Pass / Fail-Kriterium. Jetzt sind die Testschritte durcheinander und die Tests schlagen (natürlich) fehl.

Zum Beispiel:

Class testStateChanges extends TestCase

public void testCreateObjectPlacesTheObjectInStateA()
public void testTransitionToStateBAndValidateStateB()
public void testTransitionToStateCAndValidateStateC()
public void testTryToDeleteObjectinStateCAndValidateObjectStillExists()
public void testTransitionToStateAAndValidateStateA()
public void testDeleteObjectInStateAAndObjectDoesNotExist()
public void cleanupIfAnythingWentWrong()

Jede Testmethode bestätigt und meldet ihre eigenen Pass / Fail-Kriterien. Wenn Sie dies zum Zwecke der Bestellung in "eine große Testmethode" zusammenfassen, wird die Granularität der Pass / Fail-Kriterien für jeden "Schritt" im JUnit-Zusammenfassungsbericht verloren. ... und das ärgert meine Manager. Sie fordern derzeit eine andere Alternative.

Kann jemand erklären, wie eine JUnit mit verschlüsselter Testmethodenreihenfolge separate Pass / Fail-Kriterien für jeden sequentiellen Testschritt unterstützt, wie oben beispielhaft dargestellt und von meinem Management gefordert?

Unabhängig von der Dokumentation sehe ich dies als ernsthafte Regression im JUnit-Framework, die vielen Testentwicklern das Leben schwer macht.

JUnit 5 Update (und meiner Meinung nach)

Ich denke, es ist eine ziemlich wichtige Funktion für JUnit. Wenn der Autor von JUnit die Bestellfunktion nicht möchte, warum?

Standardmäßig versuchen Unit-Test-Bibliotheken nicht, Tests in der Reihenfolge auszuführen, die in der Quelldatei vorkommt.
JUnit 5 als JUnit 4 funktionieren auf diese Weise. Warum ? Denn wenn die Reihenfolge wichtig ist, bedeutet dies, dass einige Tests zwischen ihnen gekoppelt sind und dies für Komponententests unerwünscht ist .
Die @Nestedvon JUnit 5 eingeführte Funktion folgt daher demselben Standardansatz.

Bei Integrationstests kann jedoch die Reihenfolge der Testmethode von Bedeutung sein, da eine Testmethode den Status der Anwendung auf eine Weise ändern kann, die von einer anderen Testmethode erwartet wird. Wenn Sie beispielsweise einen Integrationstest für eine E-Shop-Kaufabwicklung schreiben, registriert die erste auszuführende Testmethode die Registrierung eines Kunden, die zweite das Hinzufügen von Artikeln zum Warenkorb und die letzte die Kaufabwicklung. Wenn der Testläufer diese Reihenfolge nicht einhält, ist das Testszenario fehlerhaft und schlägt fehl.
In JUnit 5 (ab Version 5.4) haben Sie dennoch die Möglichkeit, die Ausführungsreihenfolge festzulegen, indem Sie die Testklasse mit Anmerkungen versehen @TestMethodOrder(OrderAnnotation.class)und die Reihenfolge mit @Order(numericOrderValue)für die Methoden angeben, für die die Reihenfolge von Bedeutung ist.

Beispielsweise :

@TestMethodOrder(OrderAnnotation.class) 
class FooTest {

    @Order(3)
    @Test
    void checkoutOrder() {
        System.out.println("checkoutOrder");
    }

    @Order(2)
    @Test
    void addItemsInBasket() {
        System.out.println("addItemsInBasket");
    }

    @Order(1)
    @Test
    void createUserAndLogin() {
        System.out.println("createUserAndLogin");
    }
}

Ausgabe :

createUserAndLogin

addItemsInBasket

checkoutOrder

Die Angabe @TestMethodOrder(OrderAnnotation.class)scheint übrigens nicht erforderlich zu sein (zumindest in der von mir getesteten Version 5.4.0).

Randnotiz
Zur Frage: Ist JUnit 5 die beste Wahl, um Integrationstests zu schreiben? Ich denke nicht, dass dies das erste zu berücksichtigende Tool sein sollte (Cucumber und Co bringen häufig spezifischere Werte und Funktionen für Integrationstests mit), aber in einigen Integrationstestfällen reicht das JUnit-Framework aus. Das ist also eine gute Nachricht, dass die Funktion vorhanden ist.

Ich bin mir nicht sicher, ob ich damit einverstanden bin. Wenn ich "Datei-Upload" und dann "Durch Datei-Upload eingefügte Daten" testen möchte, warum möchte ich dann nicht, dass diese unabhängig voneinander sind? Ich denke, es ist absolut vernünftig, sie separat ausführen zu können, anstatt beide in einem Goliath-Testfall zu haben.

Was Sie wollen, ist durchaus sinnvoll, wenn Testfälle als Suite ausgeführt werden.

Leider ist momentan keine Zeit, eine vollständige Lösung zu geben, aber schauen Sie sich die Klasse an:

org.junit.runners.Suite

Damit können Sie Testfälle (aus jeder Testklasse) in einer bestimmten Reihenfolge aufrufen.

Diese können verwendet werden, um Funktions-, Integrations- oder Systemtests zu erstellen.

Dadurch bleiben Ihre Komponententests unverändert (wie empfohlen), unabhängig davon, ob Sie sie so ausführen oder nicht, und Sie können die Tests dann als Teil eines Gesamtbilds wiederverwenden.

Wir verwenden / erben denselben Code für Einheiten-, Integrations- und Systemtests wieder, manchmal datengesteuert, manchmal festschreibungsgesteuert und manchmal als Suite ausgeführt.

Siehe meine Lösung hier: "Junit und Java 7."

In diesem Artikel beschreibe ich, wie Junit-Tests in der richtigen Reihenfolge ausgeführt werden - "genau wie in Ihrem Quellcode". Tests werden ausgeführt, damit Ihre Testmethoden in der Klassendatei angezeigt werden.

http://intellijava.blogspot.com/2012/05/junit-and-java-7.html

Aber wie Pascal Thivent sagte, ist dies keine gute Praxis.

Mit JUnit 5.4 können Sie die Reihenfolge festlegen:

@Test
@Order(2)
public void sendEmailTestGmail() throws MessagingException {

Sie müssen nur Ihre Klasse mit Anmerkungen versehen

@TestMethodOrder(OrderAnnotation.class)

https://junit.org/junit5/docs/current/user-guide/#writing-tests-test-execution-order

Ich benutze dies in meinem Projekt und es funktioniert sehr gut!

Ich habe ein paar Antworten gelesen und bin damit einverstanden, dass dies nicht die beste Vorgehensweise ist, aber der einfachste Weg, Ihre Tests zu bestellen - und die Art und Weise, wie JUnit Tests standardmäßig ausführt, ist der aufsteigende alphabetische Name.

Benennen Sie Ihre Tests einfach in der gewünschten alphabetischen Reihenfolge. Beachten Sie auch, dass der Testname mit dem Wort test beginnen muss. Achten Sie einfach auf Zahlen

test12 wird vor test2 ausgeführt

damit:

testA_MyFirstTest testC_ThirdTest testB_ATestThatRunsSecond

Bitte überprüfen Sie diese: https://github.com/TransparentMarket/junit . Der Test wird in der angegebenen Reihenfolge ausgeführt (definiert in der kompilierten Klassendatei). Außerdem verfügt es über eine AllTests-Suite, mit der Tests ausgeführt werden können, die zuerst vom Unterpaket definiert werden. Mit der AllTests-Implementierung kann die Lösung erweitert werden, indem auch nach Eigenschaften gefiltert wird (wir haben früher @ Fast-Annotationen verwendet, diese wurden jedoch noch nicht veröffentlicht).

Hier ist eine Erweiterung von JUnit, die das gewünschte Verhalten erzeugen kann: https://github.com/aafuks/aaf-junit

Ich weiß, dass dies gegen die Autoren der JUnit-Philosophie verstößt, aber wenn Sie JUnit in Umgebungen verwenden, in denen keine strengen Unit-Tests durchgeführt werden (wie in Java praktiziert), kann dies sehr hilfreich sein.

Ich bin hier gelandet und habe gedacht, dass meine Tests nicht in der richtigen Reihenfolge durchgeführt wurden, aber die Wahrheit ist, dass das Chaos in meinen asynchronen Jobs lag. Wenn Sie mit Parallelität arbeiten, müssen Sie auch Parallelitätsprüfungen zwischen Ihren Tests durchführen. In meinem Fall teilen sich Jobs und Tests ein Semaphor, sodass die nächsten Tests hängen bleiben, bis der ausgeführte Job die Sperre aufhebt.

Ich weiß, dass dies nicht vollständig mit dieser Frage zusammenhängt, könnte aber möglicherweise helfen, das richtige Problem zu finden

Sie können einen dieser Codes verwenden:

@FixMethodOrder(MethodSorters.JVM)OR `@FixMethodOrder(MethodSorters.DEFAULT)` OR `@FixMethodOrder(MethodSorters.NAME_ASCENDING)` before your test class like this:


@FixMethodOrder(MethodSorters.NAME_ASCENDING)


public class BookTest { ...}