JUnit, 4, 5, Jupiter, Vintage

Après JUnit 5 a été publié, beaucoup de développeurs ont simplement ajouté cette nouvelle bibliothèque incroyable à leurs projets, car contrairement aux autres versions, dans cette nouvelle version, il n’est pas nécessaire de migrer de JUnit 4 à 5, vous devez simplement inclure la nouvelle bibliothèque dans votre projet, et avec tout le moteur de JUnit 5 vous pouvez faire vos nouveaux tests en utilisant JUnit 5, et les anciens tests avec JUnit 4 ou 3, continueront de fonctionner sans problème.

Mais que peut-il se passer dans un grand projet, un projet qui a été construit il y a 10 ans avec deux versions de JUnit fonctionnant en parallèle?

De nouveaux développeurs ont commencé à travailler sur le projet, certains d’entre eux ont de l’expérience avec JUnit, d’autres non. De nouveaux tests sont créés en utilisant JUnit 5, de nouveaux tests sont créés en utilisant JUnit 4, et à un moment donné un développeur sans connaissance, en créant un nouveau scénario dans un test JUnit 5 qui a déjà été créé, ils incluent simplement une annotation JUnit 4, et le test devient un mélange, certains @Test de JUnit 4 et certains @Test de JUnit 5, et chaque jour il devient plus difficile de retirer la bibliothèque JUnit 4.

Alors, comment résoudre ce problème ? tout d’abord, vous devez montrer à votre équipe ce qui vient de JUnit 5 et ce qui vient de JUnit 4, afin que les nouveaux tests soient créés en utilisant JUnit 5 plutôt qu’JUnit 4. Après cela, il est nécessaire de suivre la règle du Boy Scout, chaque fois qu’ils passent un test JUnit 4, ils doivent migrer vers JUnit 5.

Voyons les principales modifications apportées dans JUnit 5. Tout commence par le nom, dans JUnit 5, vous ne voyez plus de packages appelés org.junit5, mais plutôt org.junit.jupiter. Pour résumer, tout ce que vous voyez avec “Jupiter”, cela signifie que cela vient de JUnit 5. Ils ont choisi ce nom parce que Jupiter commence par “JU” et est la cinquième planète du système solaire.

Un autre changement concerne l’@Test, cette annotation a été déplacée vers un nouveau package : org.junit.jupiter.api et maintenant plus d’attribut comme “expected” ou “timeout” n’est utilisé, utilisez des extensions à la place. Par exemple, pour le timeout, maintenant vous avez une annotation pour cela : @Timeout(value = 100, unit = TimeUnit.MILLISECONDS). Un autre changement est que ni les méthodes de test ni les classes n’ont besoin d’être publiques.

À présent, au lieu d’utiliser @Before et @After dans votre configuration de test, vous devez utiliser @BeforeEach et @AfterEach, et vous avez également @BeforeAll et @AfterAll.

Pour ignorer les tests, maintenant vous devez utiliser @Disable au lieu de @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"));
}

Il y a tellement de fonctionnalités intéressantes dans JUnit 5, je vous recommande de consulter le Guide utilisateur de JUnit 5, pour analyser ce qui est utile à votre projet.

Maintenant que tous les développeurs savent ce qui a été changé dans JUnit 5, vous pouvez commencer le processus de suppression de JUnit 4 de votre projet. Donc, si vous utilisez toujours JUnit 4 en 2024 et que votre projet est un grand projet, vous aurez probablement certaines dépendances utilisant JUnit 4. Je vous recommande d’analyser vos bibliothèques pour vérifier si certaines d’elles utilisent JUnit 4.

Dans l’image ci-dessous, j’utilise l’analyseur de dépendances d’IntelliJ.

Comme vous pouvez le voir, jersey-test utilise JUnit 4, c’est-à-dire que même si je supprime JUnit 4 de mon projet, JUnit 4 sera disponible à utiliser parce que Jersey. La manière la plus simple serait de passer jersey à la version 2.35 car JUnit 5 a été introduit dans jersey-test 2.35, mais je ne peux pas mettre à jour le cadriciel jersey-test parce que d’autres bibliothèques se casseront dans mon projet. Donc, dans ce cas, que puis-je faire?

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. 

Quando vous exécutez certains tests qui utilisent Jersey, ils ne seront pas chargés, parce qu’il y a des méthodes dans Jersey utilisant les annotations JUnit 4, setUp et tearDown, avec @Before et @After. Pour résoudre cela, vous pouvez créer une « Classe de Configuration » qui étend JerseyTest et implémente setUp et tearDown avec @BeforeEach et @AfterEach appelant super.setUp() et super.TearDown().

public class JerseyConfigToJUnit5 extends JerseyTest {

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

Alors, si vous avez déjà vérifié vos bibliothèques et que personne n’a plus de dépendance avec JUnit 4, vous pouvez enfin migrer tous vos tests vers JUnit 5, pour ce processus, il y a un bon outil qui vous fait économiser beaucoup de travail, c’est OpenRewrite, un écosystème de refactoring automatisé pour le code source, ils changeront tous vos anciens packages, les anciennes annotations, et tout pour les nouvelles.

C’est tout les amis, maintenant vous et vos coéquipiers pouvez profiter de JUnit 5 et relâcher votre esprit en sachant que les nouveaux tests seront créés avec JUnit 5 et que le projet ne deviendra pas un Frankenstein. Alors, souvenez-vous, gardez votre projet à jour, car si vous oubliez vos bibliothèques, chaque jour sera plus difficile à mettre à jour, utilisez toujours des spécifications et des frameworks qui suivent les spécifications, et avez un bon design dans votre code, cela vous permet de changer et de vous déplacer avec facilité.