Eclipse Probleme beim Implementieren / Ausführen von jUnit 5-Test Suites

[SlitEye]

Hallo Zusammen,

ich habe eine Reihe von jUnit 4-Tests (@RunWith(JUnitPlatform.class)) und neuerdings u.a. auch erste einfache jUnit 5-Tests. Einzeln lassen sich auch alle erfolgreich ausführen.
Nun möchte ich mir gerne aus meinen Testklassen einzelne Test Suiten zusammenstellen:

Hierzu eine jUnit 5-Test-Suite (die aber auch die bisherigen jUnit 4-Testklassen ausführen können sollte):

package TestSuite.Dummy;

import org.junit.platform.runner.JUnitPlatform;
import org.junit.platform.suite.api.IncludeEngines;
import org.junit.platform.suite.api.SelectClasses;
import org.junit.platform.suite.api.SelectPackages;
import org.junit.platform.suite.api.SuiteDisplayName;
import org.junit.runner.RunWith;
import Main.Demo.*;

@RunWith(JUnitPlatform.class)
@SuiteDisplayName("JUnit 4+5 Suite Demos")
@IncludeEngines({"junit-jupiter", "junit-vintage"})
@SelectPackages({"Main.Demo"})
@SelectClasses({
   T5.class,
   T4.class,
   T2.class,    
   T3.class,
   T1.class
})
public class AllTests
{
  
}

Hierzu eine jUnit 4-TestSuite (die auch jUnit 5-Tests ausführen können sollte):

package TestSuite.Dummy;

import org.junit.platform.runner.JUnitPlatform;
import org.junit.runner.RunWith;
import org.junit.runners.Suite;
import org.junit.runners.Suite.SuiteClasses;

import Main.Demo.T1;
import Main.Demo.T2;
import Main.Demo.T3;
import Main.Demo.T4;
import Main.Demo.T5;

@RunWith(Suite.class)
//@RunWith(JUnitPlatform.class)
@SuiteClasses({
   T2.class,
   T1.class,
   T3.class,
   T4.class,
   T5.class
})
public class TestSuite_Dummy_01
{

}

Problem ist nun, dass ich mit meinem Eclipse 4.7.2 (Oxygen.2 mit Java 9.0.4 und jUnit 5) es einfach nicht hinkriege, dass die jUnit 5-Tests im jUnit 5-Modus (Eclipse: Rechtsklick > Run As > RunConfigurations... > Test runner: JUnit 5) ausgeführt werden:


Weder die obige jUnit 5-TestSuite als auch die untere jUnit 4-TestSuite führen unter Angabe des JUnitPlatform.class-Runners (im Quellcode die Annotation @RunWith) über die TestSuite keine Tests aus. Die jUnit 5-TestSuite findet laut Fehlermeldung "keine jUnit 5-Tests" (T4, T5) und auch die vorhandenen jUnit 4-Tests (T1, T2, T3) werden nicht mit ausgeführt:


Das gleiche Verhalten zeigt sich auch bei der jUnit 4-TestSuite, wenn ich via @RunWith-Annotation den JUnitPlatform.class angebe (anstatt den Suite.class-Runner).

Erst, wenn ich den jUnit 4-Modus (Eclipse: Rechtsklick > Run As > RunConfigurations... > Test runner: JUnit 4) einstelle und den Suite.class-Runner im Quelltext verwende, führt zumindest die jUnit 4-TestSuite sowohl die jUnit 4- als auch die jUnit 5-Testklassen aus:


Bei der jUnit 5-TestSuite regt sich hingegen nichts bzw. er führt zwar den Test Run der TestSuite aus, aber keinerlei jUnit 4- und 5-Tests:


Nun zu meinen Fragen/Problemen, wo ich Euch um Rat / Hilfe oder gar Lösungsvorschläge bitten möchte, da ich hier leider nicht weiter weiß:

1.)
Es muss doch möglich sein, alles - jedoch insb. jUnit 5-Tests - im jUnit 5-Modus (Eclipse: Rechtsklick > Run As > RunConfigurations... > Test runner: JUnit 5) ausführen zu lassen? Für jUnit 4-Tests kommt schließlich junit-vintage und JUnitPlatform.class-Runner zum Einsatz, ansonsten jUnit Jupiter für die 5er.
Was mache ich falsch? Im Internet finde ich leider nichts passendes.

Gerne möchte ich von den jUnit 4-TestSuites weg. Aktuell scheint diese jedoch die einzige zu sein, die alles korrekt ausführt, wenn ich im jUnit 4-Modus ausführen lasse. Aber wie gesagt, mein Ziel sollen reine jUnit 5-TestSuites mit dem JUnitPlatform.class-Runner und den neuen Annotationen (@SuiteDisplayName, @IncludeEngines, @SelectPackages, @SelectClasses) wie oben zu sehen sein und nicht die alten jUnit 4-TestSuites. Ebenso möchte ich alle meine jUnit 4-Testklassen zu jUnit 5 migrieren. Aus meiner Sicht machen dann Runs im jUnit 4-Modus einfach keinen Sinn mehr.

2.) Gemeinsame Daten zwischen den Testklassen:
Aktuell missbrauche ich aufgrund der nicht funktionierenden TestSuiten klassische jUnit 5-Tests als TestSuite-Container, mit deren Hilfe ich die anderen Testklassen bzw. der darin befindlichen Test-Funktionen ausführen lasse.
Konkret geht es um SeleniumRC-Tests. Hierzu habe ich eine eigene Klasse geschrieben, die mir meine komplette Testumgebung erstellt, inkl. erzeugen des WebDrivers.
Bisher musste ich in jeder Testklasse ein eigenes Objekt (QAE) dieser Klasse erzeugen lassen. Dadurch kann ich zwar Browsertests erfolgreich ausführen, die jedoch voneinander unabhängig laufen, weil jede Testklasse ein eigenes QAE-Objekt instanziiert. Strukturell ist meine Testklassen-Hierarchie jedoch so nicht gedacht und auch möchte ich nicht immer für jeden zu testenden Use Case alle möglichen Testfunktionen aus einer Testklasse ausführen lassen (z.B. für einen Checkout-Test - Testklasse: Bestellung - im eingeloggten Zustand, ohne die MyAccount-Seiten - zugehörig zu meiner Testklasse: Login - mit testen zu müssen).

Gibt es Möglichkeiten, dass sich mehrere Testklassen bei jedem Run ein gemeinsames (QAE)-Objekt teilen?
Und ist es möglich, dass sich Testklassen einander Daten austauschen (kommunizieren) können?
Wenn ja (jeweils), wie?

3.) Interaktions- und / oder Steuerungsmöglichkeiten in TestSuites:
Kann man bei klassischen TestSuites wie oben Daten / Objekte an die aufzurufenden Testklassen übergeben? Dies würde zumindest 2.) lösen, wenn die TestSuites denn funktionieren würden. Aber angenommen sie funktionieren irgendwann mal, wenn ja, wie kann ich in einer TestSuite Objekte an Testklassen überreichen?
Und kann man auch steuernd in den Run einer TestSuite eingreifen? Bisher gebe ich in der Testsuite nur die Testklassen an, die nacheinander abgearbeitet werden sollen. Ich würde gerne bestimmte Testklassen und sogar einzelne Funktionen daraus vom weiteren Testrun JIT ausschließen wollen, wenn eine bestimmte vorhergehende Testklasse bzw. einzelne Testfunktion fehlschlug.

Habt besten Dank schonmal im Voraus für Eure Hilfen.

VG

SlitEye

 

[mrBrown]

Es muss doch möglich sein, alles - jedoch insb. jUnit 5-Tests - im jUnit 5-Modus (Eclipse: Rechtsklick > Run As > RunConfigurations... > Test runner: JUnit 5) ausführen zu lassen? Für jUnit 4-Tests kommt schließlich junit-vintage und JUnitPlatform.class-Runner zum Einsatz, ansonsten jUnit Jupiter für die 5er.
Was mache ich falsch? Im Internet finde ich leider nichts passendes.

Gerne möchte ich von den jUnit 4-TestSuites weg. Aktuell scheint diese jedoch die einzige zu sein, die alles korrekt ausführt, wenn ich im jUnit 4-Modus ausführen lasse. Aber wie gesagt, mein Ziel sollen reine jUnit 5-TestSuites mit dem JUnitPlatform.class-Runner und den neuen Annotationen (@SuiteDisplayName, @IncludeEngines, @SelectPackages, @SelectClasses) wie oben zu sehen sein und nicht die alten jUnit 4-TestSuites. Ebenso möchte ich alle meine jUnit 4-Testklassen zu jUnit 5 migrieren. Aus meiner Sicht machen dann Runs im jUnit 4-Modus einfach keinen Sinn mehr.

Ich meine, in anderem Kontext gelesen zu haben, dass Suites in IDEs aktuell noch Probleme machen (kann mich aber auch irren), über passende Build-Tools sollte das aber klappen

2.) Gemeinsame Daten zwischen den Testklassen:

Für mich zumindest bei Unit-Tests ein absolutes No-Go, die würde ich immer maximal unabhängig voneinander halten - deshalb kann ich da nicht mehr zu sagen als "vermeide es"

3.) Interaktions- und / oder Steuerungsmöglichkeiten in TestSuites:

Würde ich wegen Punkt 2 auch vermeiden.
uU sind allerdings Assumptions interessant, um Tests bei falschen Vorbedingungen abbrechen zu lassen.

 

[SlitEye]

Danke mrBrown, das (unabhängige Tests) ist natürlich eine Möglichkeit, leider keine Zielführende, da die Testklassenstruktur historisch modularisiert gewachsen ist. Da lässt sich leider nichts rütteln, zu viel Umbauarbeiten wären da nötig. Voneinander abhängige Tests machen insofern schon Sinn, wenn man sie mehrfach wiederverwenden möchte. Wie dem auch sei, ich bräuchte wirklich Hilfe beim vorliegenden Fall. Primär wäre es erstmal schon, überhaupt die jUnit 5-TestSuite im jUnit 5-Modus von Eclipse zum Laufen zu bekommen.

 

[mrBrown]

Voneinander abhängige Tests machen insofern schon Sinn, wenn man sie mehrfach wiederverwenden möchte.

Nein, machen sie nicht. Wenn man gemeinsame Funktionalität braucht, führt man sie einfach explizit aus...

das (unabhängige Tests) ist natürlich eine Möglichkeit, leider keine Zielführende, da die Testklassenstruktur historisch modularisiert gewachsen ist. Da lässt sich leider nichts rütteln, zu viel Umbauarbeiten wären da nötig.

Dann bleib doch einfach bei der bisherigen, funktionierenden Variante?
Wenn du es sowieso nicht wirklich refactoren willst, warum dann zwingend auf Junit 5 migrieren? Führt in dem Fall ja offensichtlich zu mehr Probleme, als sie lösen?

 

[SlitEye]

Es sind nur die oben beschriebenen Probleme. Alles andere funktioniert weitestgehend.
Es ist einfach unsere Anforderung. Da ist nichts mit "bleib doch bei der bisherigen Variante".

 

[mrBrown]

Es ist einfach unsere Anforderung. Da ist nichts mit "bleib doch bei der bisherigen Variante".

afaik ist sowohl eine feste Reihenfolge der Tests als auch das Ausführen von Suite's mit IDE aktuell nicht möglich.

Anforderungen, die sich technisch nicht umsetzen lassen, sind schon ein bisschen ... dumm

 

[SlitEye]

naja, ich kann via Test Suite schon die Testreihenfolge definieren und kann sie auch via IDE ausführen. Ich würde halt gerne im jUnit 5-Modus ausführen und nicht nur im jUnit 4-Modus (was funktioniert). Es gibt viele bebilderte Anleitungen, wo man sieht, dass man es mit Eclipse sehr wohl ausführen kann. Was mache ich falsch?

 

[mrBrown]

Nichts machst du falsch.
Wie gesagt: Tests mit fixer Reihenfolge haben bisher keinen Support seitens JUnit 5 und das ausführen von Suites hab ich bisher nur mit @RunWith, was eben JUnit 4 bedeutet, gesehen und macht afair auch noch Probleme in IDEs.

Wie sieht dass ganze denn unabhängig von der IDE beim bauen über die Konsole aus?

 

[SlitEye]

Na ok, dann scheint der Fehler wohl nicht bei mir zu liegen. Gut, dann wohl erstmal weiter im jUnit 4-Mode.

Bleibt das Problem mit Frage 2 und 3.
Langsam verzweifel ich dran.

 

[mrBrown]

Für 2 wären Nested-Tests uU das passendste
Für 3 bräuchte man eben eine feste Reihenfolge. Ist uU möglich, wenn Test-Szenarien in JUnit5 umgesetzt sind, dass dürfte etwas in die Richtung gehen.

 

[SlitEye]

bei @Nested-Tests ist doch aber wieder das Problem, dass dies alles in einer Testklasse implementiert wird.
Das bringt mich nicht wirklich weiter, da die bisherigen Testklassen auch nicht in einer Datei sind und ich möchte eigentlich ungern alle meine Testklassen in eine einzige packen, da das dann nicht mehr komfortabel wartbar wäre.

 

[SlitEye]

@Nested-Test Classes scheinen in der Tat die Lösung für junit 5 zu sein. Habt Ihr eine Idee, dass man nicht alle Klassen in eine Datei schreiben muss?
Man quasi die inneren nested Testklassen in seperate Dateien auslagert, sie aber dennoch in die Root-Testklasse einbinden kann als wäre sie direkt in der Root-Testklasse geschrieben.
Weil, wie gesagt, bei uns müssen mehrere am Projekt mitarbeiten können. Da wäre es hinderlich, wenn alle in derselben Datei herum mehren. Wenn wir jedoch eine Datei-basierte Hierarchie von nested Testklassen realisieren können, wäre dies die Lösung und wir könnten nur noch junit 5 praktizieren.

 

[mrBrown]

Nested-Classes bauen auf inneren Klassen auf, das dürfte nicht anders umsetzbar sein.

 

[SlitEye]

Nunja, ich habe mal was gebastelt, was vielversprechend ausschaut:

Ziel: Nested-Testklassen aus folgender Root-Testklasse "T7" in seperate Files auslagern und diese jedoch mit in die Root-Testklasse weiterhin integrieren:

T7.java: Ausgangslage

package Main.Demo;

import static org.junit.jupiter.api.Assertions.*;

import org.junit.jupiter.api.AfterAll;
import org.junit.jupiter.api.AfterEach;
import org.junit.jupiter.api.BeforeAll;
import org.junit.jupiter.api.BeforeEach;
import org.junit.jupiter.api.DisplayName;
import org.junit.jupiter.api.Nested;
import org.junit.jupiter.api.Test;
import org.junit.jupiter.api.TestInstance;
import org.junit.jupiter.api.extension.ExtendWith;
import org.junit.platform.runner.JUnitPlatform;
import org.junit.runner.RunWith;

import ISHQA.StdLibCore.jUnit.ClientDescriptionParameterResolver;

@RunWith(JUnitPlatform.class) //is necessary to run jUnit 5 tests with non-junit5-implemented IDEs
@Nested
@TestInstance(TestInstance.Lifecycle.PER_CLASS)
@ExtendWith(ClientDescriptionParameterResolver.class)
@DisplayName("Test class 7")
class T7
{
    @BeforeAll
    static void setUpBeforeClass() throws Exception
    {
    }

    @AfterAll
    static void tearDownAfterClass() throws Exception
    {
    }

    @BeforeEach
    void setUp() throws Exception
    {
    }

    @AfterEach
    void tearDown() throws Exception
    {
    }

    @Nested
    @DisplayName("First Group")
    class T71
    {
        @Test
        @DisplayName("Test A")
        void test()
        {
            //fail("Not yet implemented");
        }
    }

    @Nested
    @DisplayName("Second Group")
    class T72
    {
        @Test
        @DisplayName("Test B")
        void test()
        {
            //fail("Not yet implemented");
        }
    }
}

HOFFENTLICH MÖGLICHE LÖSUNG:

AllTests2.java: zum starten meiner Root-Testklasse

package TestSuite.Dummy;

import org.junit.platform.runner.JUnitPlatform;
import org.junit.runner.RunWith;
import org.junit.runners.Suite;
import org.junit.runners.Suite.SuiteClasses;

import com.github.peterwippermann.junit4.parameterizedsuite.ParameterizedSuite;

import Main.Demo.T5;
import Main.Demo.T8;

@RunWith(Suite.class)
//@RunWith(ParameterizedSuite.class)
//@RunWith(JUnitPlatform.class)
@SuiteClasses({
  T8.class
})
public class AllTests2
{
}

T8.java: Neue Root-Testklasse (ehem. T7.java)

package Main.Demo;

import static org.junit.jupiter.api.Assertions.*;

import org.junit.jupiter.api.AfterAll;
import org.junit.jupiter.api.AfterEach;
import org.junit.jupiter.api.BeforeAll;
import org.junit.jupiter.api.BeforeEach;
import org.junit.jupiter.api.DisplayName;
import org.junit.jupiter.api.Nested;
import org.junit.jupiter.api.Test;
import org.junit.jupiter.api.TestInstance;
import org.junit.jupiter.api.extension.ExtendWith;
import org.junit.platform.runner.JUnitPlatform;
import org.junit.runner.RunWith;

import ISHQA.StdLibCore.jUnit.ClientDescriptionParameterResolver;

@RunWith(JUnitPlatform.class) //is necessary to run jUnit 5 tests with non-junit5-implemented IDEs
@TestInstance(TestInstance.Lifecycle.PER_CLASS)
@ExtendWith(ClientDescriptionParameterResolver.class)
@DisplayName("Test class 8")
public class T8
{
    public static String word = "Hallo";
    //public static String wort;
 
    public T8()
    {
        this.word = "World";
        //wort = new String("Merkel");
    }
 
    @BeforeAll
    public static void setUpBeforeClass() throws Exception
    {
    }

    @AfterAll
    public static void tearDownAfterClass() throws Exception
    {
    }

    @BeforeEach
    public void setUp() throws Exception
    {
    }

    @AfterEach
    public void tearDown() throws Exception
    {
    }
 
    @Nested
    @DisplayName("First Group")
    public class innerT81 extends T81
    {
    }
 
    @Nested
    @DisplayName("Second Group")
    public class innerT82 extends T82
    {
    }
}

T81.java: ausgelagerte Nested Test Class T81 (ehem. @Nested class T71)

package Main.Demo;

import static org.junit.jupiter.api.Assertions.*;

import org.junit.jupiter.api.AfterAll;
import org.junit.jupiter.api.AfterEach;
import org.junit.jupiter.api.BeforeAll;
import org.junit.jupiter.api.BeforeEach;
import org.junit.jupiter.api.DisplayName;
import org.junit.jupiter.api.Nested;
import org.junit.jupiter.api.Test;
import org.junit.jupiter.api.TestInstance;
import org.junit.jupiter.api.extension.ExtendWith;
import org.junit.platform.runner.JUnitPlatform;
import org.junit.runner.RunWith;

import ISHQA.StdLibCore.jUnit.ClientDescriptionParameterResolver;

@RunWith(JUnitPlatform.class) //is necessary to run jUnit 5 tests with non-junit5-implemented IDEs
@Nested
@TestInstance(TestInstance.Lifecycle.PER_CLASS)
@ExtendWith(ClientDescriptionParameterResolver.class)
@DisplayName("First Group")
public class T81
{
    public T81()
    {
        super();
    }
 
    @BeforeAll
    public static void setUpBeforeClass() throws Exception
    {
    }

    @AfterAll
    public static void tearDownAfterClass() throws Exception
    {
    }

    @BeforeEach
    public void setUp() throws Exception
    {
    }

    @AfterEach
    public void tearDown() throws Exception
    {
    }

    @Test
    @DisplayName("Test A")
    public void test()
    {
        System.out.println(T8.word);
        //fail("Not yet implemented");
    }

}

T82.java: Ausgelagerte Nested Test Class T82 (ehem. @Nested class T72)

package Main.Demo;

import static org.junit.jupiter.api.Assertions.*;

import org.junit.jupiter.api.AfterAll;
import org.junit.jupiter.api.AfterEach;
import org.junit.jupiter.api.BeforeAll;
import org.junit.jupiter.api.BeforeEach;
import org.junit.jupiter.api.DisplayName;
import org.junit.jupiter.api.Nested;
import org.junit.jupiter.api.Test;
import org.junit.jupiter.api.TestInstance;
import org.junit.jupiter.api.extension.ExtendWith;
import org.junit.platform.runner.JUnitPlatform;
import org.junit.runner.RunWith;

import ISHQA.StdLibCore.jUnit.ClientDescriptionParameterResolver;

@RunWith(JUnitPlatform.class) //is necessary to run jUnit 5 tests with non-junit5-implemented IDEs
@Nested
@TestInstance(TestInstance.Lifecycle.PER_CLASS)
@ExtendWith(ClientDescriptionParameterResolver.class)
@DisplayName("Second Group")
public class T82
{
    public T82()
    {
        super();
    }
 
    @BeforeAll
    public static void setUpBeforeClass() throws Exception
    {
    }

    @AfterAll
    public static void tearDownAfterClass() throws Exception
    {
    }

    @BeforeEach
    public void setUp() throws Exception
    {
    }

    @AfterEach
    public void tearDown() throws Exception
    {
    }

    @Test
    @DisplayName("Test B")
    public void test()
    {
        //fail("Not yet implemented");
    }

}

Das scheint zu funktionieren:


Im nächsten Schritt werde ich überprüfen wie verträglich @ParameterizedTest's im Zusammenspiel solcher ausgelagerten @Nested-Test Classes funktionieren.

Eine Lösung für Parameterübergabe von TestSuite zu Test Classes habe ich auch bereits und zwar durch eine weitere externe Klasse, die public static-Variablen vorhält, auf die sowohl meine Suites als auch die Testklassen Zugriff haben (Suites schreibender Zugriff für Init, Test Classes lesender Zugriff für Ausführung).
Ist zwar sehr russisch das Ganze, aber wenigstens funktionierend (korrigiert mich, wenn ich falsch liege).

Zusätzlich muss ich für jeden Mandanten/-Channel (Shop mit mehreren Channels) halt mehrere Suites erstellen und seperat ausführen, zumindest solange, bis die anderen oben genannten Probleme im Zusammenhang mit dem JUnitPlatform.class-Runner (jUnit4+5) und dem com.github.peterwippermann.junit4.parameterizedsuite.ParameterizedSuite.class-Runner überwunden sind.
Mit letzterem bräuchte ich so nur noch eine oder wenige TestSuites, da diese damit parametrisiert seien. Das Problem ist da, dass ich über solche parametrisierten Suites nur über den Parameterized.class-Runner in den Testklassen an die Parameter der Suite heran komme.

Wenn hier irgendwer weiß, wie man die beiden Runner (JUnitPlatform.class für Test Classes und ParameterizedSuite.class für TestSuites) irgendwie verheiraten kann, lasst es mich bitte wissen.

VG

SlitEye

 

[mrBrown]

Die externen Nested-Klassen sollten dann aber noch abstrakt sein
Ich weiß allerdings nicht, ob das so noch irgendwie zu Probleme führen kann...