La nouvelle version de JUnit est sortie depuis le 17 septembre.
L’aventure a commencé en 2015 par une campagne de crowdfunding. Cette nouvelle version majeure arrive plus de 10 ans après JUnit 4.
Penchons-nous sur les nouveautés de JUnit 5 !

Découpage des dépendances

Tout d’abord, le groupId et les dépendances ont été renommées.
Nous retrouverons tout sous le groupId `org.junit.jupiter` et les dépendances qui nous intéressent sont :
– `junit-jupiter-api` : qui définit l’api de JUnit 5 (les annotations, etc.)
– `junit-jupiter-engine` : le moteur de JUnit 5 qui lance les tests écrits via l’api
– `junit-platform-launcher` : le lanceur utilisé par l’outil de build qui appelle le moteur

Annotations et syntaxe

Comme JUnit 4, JUnit 5 fonctionne avec des annotations. Cependant il y a quelques changements et nouveautés :
– l’annotation `@Test` ne prend plus de paramètres. La capture des exceptions et des timeouts est déléguée à la librairie d’assertion (fournie avec JUnit 5).
– l’annotation `@Before` est renommée `@BeforeEach` pour plus de clarté
– l’annotation `@BeforeClass` est renommée `@BeforeAll` pour la même raison
– de même pour `@After` et `@AfterClass` qui deviennent respectivement `@AfterEach` et `@AfterAll`
– l’annotation `@DisplayName` permet de donner un nom arbitraire à une classe de test ou à un test
– l’annotation `@Nested` permet d’imbriquer une classe de test dans une classe de test. Cela permet notamment de découper ses tests en contextes comme le permettent les fonctions `describe` et `it` en javascript par exemple. Cela permet d’avoir des tests qui ressemblent à de la documentation.
– il n’est plus nécessaire de déclarer ses classes de test et ses tests en tant que `public`, `package protected` (pas de mot clé) est suffisant.
Voilà ce que je retiens de l’usage basique de cette nouvelle version. À noter également que la libraire d’assertion reste assez légère et que je recommande d’utiliser une librairie annexe comme `AssertJ`.

Tests paramétrés et dynamiques

JUnit 5 permet d’écrire des tests paramétrés simplement.
Ainsi, si plusieurs tests sont des copiés collés à quelques valeurs près, il est désormais possible de n’écrire qu’un seul test qui reçoit en paramètre ces valeurs.
JUnit 5 permet entre autre de passer ces valeurs directement via une annotation ou en indiquant une méthode qui fournira les arguments à passer aux tests.
Adieu donc les frameworks de tests paramétrés !
Plus puissant encore, JUnit 5 nous permet d’écrire du code qui produit des tests qui sont exécutés. Je pense que le cas d’usage de cette fonctionnalité est rare mais la puissance est là !

Extension

Enfin, JUnit 5 permet d’écrire très simplement des extensions. Cela permet de remplacer les runners et les rules de JUnit 4.
En effet, plusieurs extensions peuvent tourner sur les mêmes tests.
On notera notamment l’extension de Spring et de Mockito qui peuvent désormais fonctionner ensemble simplement.
Un prochain article parlera de l’extension JUnit5-Docker.

Compatibilité avec JUnit 4

“Et mon code legacy qui utilise JUnit 4 dans tout ça ?” dites-vous ?
Eh bien figurez-vous qu’ils y ont pensé : grâce à l’artefact `junit-vintage-engine`, il est possible de conserver ses tests JUnit 4 tout en écrivant les nouveaux avec JUnit 5. La seule « contrainte » est qu’il faut utiliser Java 8 à minimum. Aucune raison d’attendre ou de planifier un gros big bang pour changer de librairie !

Conclusion

À l’usage quotidien, JUnit 5 apporte son lot de nouveautés (notamment les tests paramétrés et les extensions) et rend son utilisation bien plus aisée et agréable !
Alors… pourquoi attendre ?