JUnit, 4, 5, Jupiter, Vintage

Na JUnit 5 is uitgebracht, hebben veel ontwikkelaars deze geweldige nieuwe bibliotheek toegevoegd aan hun projecten, omdat je in tegenstelling tot andere versies in deze nieuwe versie niet hoeft over te stappen van JUnit 4 naar 5; je hoeft alleen de nieuwe bibliotheek in je project op te nemen, en met de volledige motor van JUnit 5 kun je je nieuwe tests uitvoeren met JUnit 5, en de oude tests met JUnit 4 of 3 blijven zonder problemen draaien.

Wat kan er echter gebeuren in een groot project, een project dat tien jaar geleden is gebouwd en waarbij parallel twee versies van JUnit worden gebruikt?

Nieuwe ontwikkelaars zijn begonnen aan het project, sommigen met ervaring in JUnit, anderen niet. Nieuwe tests worden gemaakt met JUnit 5, nieuwe tests worden gemaakt met JUnit 4, en op een gegeven moment creëert een ontwikkelaar zonder kennis een nieuw scenario in een reeds bestaande JUnit 5-test en voegt simpelweg een JUnit 4-annotatie toe, waardoor de test een mix wordt van sommige @Test van JUnit 4 en sommige @Test van JUnit 5, en het wordt elke dag moeilijker om de JUnit 4-bibliotheek te verwijderen.

Dus, hoe los je dit probleem op? Ten eerste moet je aan je team tonen wat van JUnit 5 is en wat van JUnit 4, zodat nieuwe tests worden gemaakt met JUnit 5 in plaats van JUnit 4. Daarna is het nodig om de Boy Scout-regel te volgen, elke keer dat ze een JUnit 4-test passeren moeten ze migreren naar JUnit 5.

Laten we de belangrijkste wijzigingen bekijken die zijn vrijgegeven in JUnit 5. Het begint allemaal bij de naam, in JUnit 5 zie je geen pakketten genaamd org.junit5, maar eerder org.junit.jupiter. Samengevat, alles wat je ziet met “Jupiter” betekent dat het van JUnit 5 is. Ze hebben deze naam gekozen omdat Jupiter begint met “JU” en de vijfde planeet van de zon is.

Een andere wijziging heeft te maken met de @Test-annotatie, deze annotatie is verplaatst naar een nieuw pakket: org.junit.jupiter.api en nu wordt er geen attribuut zoals “expected” of “timeout” meer gebruikt, maar in plaats daarvan een extensie. Bijvoorbeeld, voor timeout heb je nu één annotatie voor dit doel: @Timeout(value = 100, unit = TimeUnit.MILLISECONDS). Een andere wijziging is dat noch testmethoden noch klassen publiek hoeven te zijn.

Nu moet je in plaats van @Before en @After gebruiken in je testconfiguratie, @BeforeEach en @AfterEach gebruiken, en je hebt ook @BeforeAll en @AfterAll.

Om tests over te slaan, moet je nu @Disable gebruiken in plaats van @Ignore.

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"));
}

Er zijn zoveel leuke functies in JUnit 5, ik raad je aan om de JUnit 5 Gebruikershandleiding te bekijken, om te analyseren wat nuttig is voor je project.

Nu alle ontwikkelaars weten wat er is gewijzigd in JUnit 5, kunt u beginnen met het verwijderen van JUnit 4 uit uw project. Dus, als u nog steeds JUnit 4 gebruikt in 2024 en uw project is een groot project, zult u waarschijnlijk enkele afhankelijkheden hebben die JUnit 4 gebruiken. Ik raad u aan uw bibliotheken te analyseren om te controleren of sommige van hen JUnit 4 gebruiken.

In de afbeelding hieronder gebruik ik Dependency Analyzer van IntelliJ.

Zoals u kunt zien, gebruikt jersey-test JUnit 4, dat wil zeggen, zelfs als ik JUnit 4 uit mijn project verwijder, zal JUnit 4 beschikbaar zijn om te gebruiken vanwege Jersey. De eenvoudigste manier zou zijn om jersey op te waarderen naar 2.35 omdat JUnit 5 is geïntroduceerd in jersey-test 2.35, maar ik kan het jersey-test framework niet bijwerken omdat andere bibliotheken in mijn project zullen breken. Dus, in dit geval, wat kan ik doen?

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. 

Als u enkele tests uitvoert die Jersey gebruiken, zullen ze niet worden geladen, omdat er methoden in Jersey zijn die JUnit 4 annotaties gebruiken, setUp en tearDown, met @Before en @After. Om dit op te lossen, kunt u één “Configuratieklasse” maken die JerseyTest extends en setUp en tearDown implementeert met @BeforeEach en @AfterEach door super.setUp() en super.TearDown() aan te roepen.

public class JerseyConfigToJUnit5 extends JerseyTest {

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

Zo, als je al je bibliotheken hebt gecontroleerd en niemand heeft meer afhankelijkheden van JUnit 4, kun je eindelijk al je tests migreren naar JUnit 5. Voor dit proces is er een goed hulpmiddel dat je veel werk bespaart, namelijk OpenRewrite, een geautomatiseerd refactoring-ecosysteem voor broncode. Zij zullen al je oude pakketten, de oudere annotaties, en alles naar de nieuwe versie aanpassen.

Dat is alles, mensen. Nu kunnen jij en je teamgenoten van JUnit 5 genieten en je zorgen minder maken, wetende dat nieuwe tests met JUnit 5 zullen worden gemaakt en het project geen monster zal worden. Onthoud dus, hou je project up-to-date, omdat als je je bibliotheken vergeet, het elke dag moeilijker wordt om te updaten. Gebruik altijd specificaties en frameworks die de specificaties volgen, en zorg voor een goed ontwerp in je code. Dit stelt je in staat om gemakkelijk te veranderen en te verhuizen.