JUnit, 4, 5, Jupiter, Vintage

Nach der Veröffentlichung von JUnit 5 haben viele Entwickler diese großartige neue Bibliothek zu ihren Projekten hinzugefügt, denn im Gegensatz zu anderen Versionen ist es in dieser neuen Version nicht notwendig, von JUnit 4 auf 5 zu migrieren. Sie müssen nur die neue Bibliothek in Ihr Projekt aufnehmen, und mit dem gesamten Motor von JUnit 5 können Sie neue Tests mit JUnit 5 durchführen und die alten Tests mit JUnit 4 oder 3 werden ohne Probleme weiterlaufen.

Was aber in einem großen Projekt passieren kann, einem Projekt, das vor 10 Jahren mit zwei Versionen von JUnit parallel erstellt wurde?

Neue Entwickler haben begonnen, an dem Projekt zu arbeiten, einige von ihnen mit JUnit-Erfahrung, andere nicht. Neue Tests werden mit JUnit 5 erstellt, neue Tests werden mit JUnit 4 erstellt, und irgendwann wird ein Entwickler ohne Wissen, wenn sie ein neues Szenario in einem bereits erstellten JUnit 5-Test erstellen, einfach eine JUnit 4-Anmerkung einfügen, und der Test wird zu einer Mischung aus einigen @Test von JUnit 4 und einigen @Test von JUnit 5, und es wird jeden Tag schwieriger, die JUnit 4-Bibliothek zu entfernen.

Wie also löst man dieses Problem? Zunächst müssen Sie Ihrem Team zeigen, was von JUnit 5 und was von JUnit 4 ist, damit neue Tests mit JUnit 5 anstatt mit JUnit 4 erstellt werden. Danach ist es notwendig, die Boy Scout-Regel zu befolgen, whenever sie einen JUnit 4-Test durchlaufen lassen, müssen sie zu JUnit 5 migrieren.

Schauen wir uns die Hauptänderungen an, die in JUnit 5 veröffentlicht wurden. Alles beginnt mit dem Namen, in JUnit 5 siehst du keine Pakete mehr mit org.junit5, sondern eher org.junit.jupiter. Zusammengefasst, alles was du mit „Jupiter“ siehst, bedeutet das, es stammt von JUnit 5. Sie haben diesen Namen gewählt, weil Jupiter mit „JU“ beginnt und der fünfte Planet vom Sonnen远离地球 ist.

Eine andere Änderung betrifft die @Test-Annotation, diese wurde in ein neues Paket verschoben: org.junit.jupiter.api und jetzt wird kein Attribut wie „expected“ oder „timeout“ mehr verwendet, stattdessen werden Erweiterungen verwendet. Zum Beispiel, für Timeout, hast du jetzt eine separate Annotation dafür: @Timeout(value = 100, unit = TimeUnit.MILLISECONDS). Eine weitere Änderung ist, dass weder Testmethoden noch Klassen öffentlich sein müssen.

Jetzt musst du anstelle von @Before und @After in deiner Testkonfiguration @BeforeEach und @AfterEach verwenden, und du hast auch @BeforeAll und @AfterAll.

Um Tests zu ignorieren, musst du jetzt @Disable anstatt @Ignore verwenden.

A great news that was released in JUnit 5 was the annotation @ParameterizedTest, with that is possible to run one test multiple times with different arguments. For example, if you want to test a method that creates some object and you want to validate if the fields are filled correctly, you just do the following:

@ParameterizedTest
@MethodSource("getInvalidSources")
void shouldCheckInvalidFields(String name, String job, String expectedMessage) {
	Throwable exception = catchThrowable(() -> new Client(name, job));
  
  	assertThat(exception).isInstanceOf(IllegalArgumentException.class)
      .hasMessageContaining(expectedMessage);
}

static Stream<Arguments> getInvalidSources() {
	return Stream.of(Arguments.arguments("Jean Donato", "", "Job is empty"),
                     Arguments.arguments("", "Dev", "Name is empty"));
}

Es gibt viele tolle Funktionen in JUnit 5, ich empfehle dir das JUnit 5 Nutzerhandbuch zu überprüfen, um zu analysieren, was für dein Projekt nützlich ist.

Jetzt, da alle Entwickler wissen, was in JUnit 5 geändert wurde, können Sie mit dem Prozess beginnen, JUnit 4 aus Ihrem Projekt zu entfernen. Wenn Sie also immer noch JUnit 4 im Jahr 2024 verwenden und Ihr Projekt ein großes Projekt ist, werden Sie wahrscheinlich einige Abhängigkeiten haben, die JUnit 4 verwenden. Ich empfehle Ihnen, Ihre Bibliotheken zu analysieren, um zu überprüfen, ob einige von ihnen JUnit 4 verwenden.

In dem folgenden Bild verwende ich den Dependency Analyzer von IntelliJ.

Wie Sie sehen können, verwendet jersey-test JUnit 4, das heißt, selbst wenn ich JUnit 4 aus meinem Projekt entferne, wird JUnit 4 aufgrund von Jersey verfügbar sein. Der einfachste Weg wäre es, jersey auf 2.35 zu aktualisieren, da JUnit 5 in jersey-test 2.35 eingeführt wurde, aber ich kann das jersey-test Framework nicht aktualisieren, da andere Bibliotheken in meinem Projekt kaputt gehen würden. Was kann ich also in diesem Fall tun?

I can exclude JUnit from Jersey with Dependency Exclusions from Maven (like the image below). That way JUnit 4 will not be used anymore, but rather our JUnit 5. 

Wenn Sie einige Tests ausführen, die Jersey verwenden, werden diese nicht geladen, weil es in Jersey Methoden gibt, die JUnit 4-Annotierungen verwenden, setUp und tearDown, mit @Before und @After. Um dies zu lösen, können Sie eine „Konfigurationsklasse“ erstellen, die JerseyTest erweitert und setUp und tearDown mit @BeforeEach und @AfterEach implementiert, die super.setUp() und super.TearDown() aufrufen.

public class JerseyConfigToJUnit5 extends JerseyTest {

  @BeforeEach
  public void setUp() throws Exception {
  	super.setUp();
  }
  
  @AfterEach
  public void tearDown() throws Exception {
  	super.tearDown();
  }
}

Also haben Sie bereits Ihre Bibliotheken überprüft und festgestellt, dass niemand eine größere Abhängigkeit von JUnit 4 hat, können Sie schließlich alle Ihre Tests auf migrieren JUnit 5, für diesen Prozess gibt es ein gutes Tool, das Ihnen viel Arbeit erspart, nämlich OpenRewrite, eine automatisierte Refaktorisierungsumgebung für Quellcode, sie werden alle Ihre alten Pakete, die älteren Annotationen und alles auf die neue Version umstellen.

Das ist alles, Leute, jetzt können Sie und Ihre Teamkollegen JUnit 5 genießen und sich entspannen, indem Sie wissen, dass neue Tests mit JUnit 5 erstellt werden und das Projekt nicht zu einem Frankenstein wird. Also denken Sie daran, Ihr Projekt auf dem neuesten Stand zu halten, denn wenn Sie Ihre Bibliotheken vergessen, wird es jeden Tag schwieriger, zu aktualisieren, verwenden Sie immer Spezifikationen und Frameworks, die diesen folgen, und haben Sie eine gute Designsstruktur in Ihrem Code, das ermöglicht es Ihnen, flexibel zu ändern und zu bewegen.