Einen Unit-Test in JUnit 5 und xUnit.net schreiben: Annotationen, Lifecycle und parametrisierte Fälle im Vergleich

Ziel

Einen Test schreiben, den auch Lesende aus dem jeweils anderen Ökosystem sofort wiedererkennen: ein Verhalten je Test, sichtbares Setup, wiederholte Fälle als Daten ausgedrückt.

Voraussetzungen

JUnit Jupiter (junit-jupiter im Test-Classpath, junit-jupiter-params für parametrisierte Tests) oder xUnit.net (xunit plus ein Runner) in einem Projekt, dessen Build bereits Tests ausführt; Vertrautheit mit dem allgemeinen Artikel zur Unit-Test-Struktur in diesem Wiki.

Schritte

1. Die Klasse nach der Einheit benennen und die Methode nach dem Verhalten: OrderTotalTest.appliesDiscountAboveThreshold() in Java, OrderTotalTests.AppliesDiscountAboveThreshold() in C#.
2. Den Test markieren: JUnit @Test aus org.junit.jupiter.api; xUnit [Fact]. Beide Frameworks instanziieren die Testklasse standardmässig für jede Testmethode neu: Die JUnit-Dokumentation beschreibt den Per-Method-Lifecycle und den Schalter @TestInstance(Lifecycle.PER_CLASS), und die xUnit-Seite zum geteilten Kontext hält fest, dass der Konstruktor für jeden einzelnen Test läuft.
3. Das Setup je Test dort platzieren, wo das Framework es erwartet: bei JUnit die Methoden @BeforeEach und @AfterEach; bei xUnit den Konstruktor und Dispose(), oder IAsyncLifetime, wenn das Setup asynchron ist. Zustand in Instanzfeldern halten, nicht in statischen.
4. Teuren Kontext bewusst teilen: bei JUnit @BeforeAll an einer statischen Methode (nicht-statisch unter dem Per-Class-Lifecycle); bei xUnit IClassFixture<T> für eine Fixture-Instanz je Testklasse und ICollectionFixture<T> über Klassen hinweg, beide vor dem ersten Test erzeugt und nach dem letzten entsorgt.
5. Kopierte Tests in Daten verwandeln: bei JUnit @ParameterizedTest mit @ValueSource, @CsvSource oder @MethodSource (die Dokumentation verlangt mindestens eine Source); bei xUnit [Theory] mit [InlineData(...)], [MemberData] oder [ClassData].
6. Ein Verhalten prüfen: bei JUnit assertEquals(expected, actual), assertThrows(Type.class, () -> ...), assertAll(...), um zusammengehörige Assertions zu gruppieren; bei xUnit Assert.Equal(expected, actual), Assert.Throws<T>(() => ...). Beide stellen den erwarteten Wert voran.
7. Einen Test von der Kommandozeile ausführen, um die Verdrahtung zu belegen: ./gradlew test --tests OrderTotalTest oder ./mvnw -Dtest=OrderTotalTest test; dotnet test --filter FullyQualifiedName~OrderTotalTests.

Erwartetes Ergebnis

Jede Testdatei liest sich in beiden Sprachen gleich: Konstruktion, Aktion, Assertion; Parametertabellen ersetzen duplizierte Methoden; der Aufwand des Setups ist im Lifecycle-Hook sichtbar, der ihn trägt.

Grenzen und Prüfbasis

Assertion-Bibliotheken (AssertJ, Hamcrest, FluentAssertions, Shouldly) ändern die Syntax von Schritt 6, nicht die Struktur. Die parallele Ausführung unterscheidet sich zwischen den Frameworks und muss vor der gemeinsamen Nutzung von statischem Zustand durch Tests in deren Dokumentation geprüft werden. Das Vorgehen folgt der zitierten Dokumentation; es wird kein Vergleich von Geschwindigkeit oder Fehlerraten behauptet.