Quoi de neuf avec Junit 5 ?

0

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 ?

Partagez cet article.

A propos de l'auteur

Xavier travaille comme développeur et leader technique Java depuis plusieurs années et suit de très près les nombreuses avancées dans le domaine. Expert sur Struts, Spring, Hibernate, JUnit, TestNG, Mockito, Apache commons, Xavier est aussi adepte du Craftsmanship. "La pédagogie et le partage des bonnes pratiques dans un esprit convivial et ludique" est bel et bien son crédo.

Ajouter un commentaire