JUnit 5 essentiel
Cycle de vie, assertions, tests paramétrés et noms qui expliquent l'échec.
JUnit 5 en pratique
Un test qui échoue sur expected: <true> but was: <false> dans une méthode appelée testCalcul2 vous coûte un quart d'heure : il faut ouvrir le fichier, relire la configuration, reconstituer l'intention de l'auteur. Le même test, nommé un_retrait_superieur_au_solde_est_refuse et se terminant par une assertion AssertJ qui affiche l'objet complet, vous coûte cinq secondes. La différence n'est pas cosmétique — elle décide si votre suite est un outil de diagnostic ou une alarme sans contexte.
JUnit 5 n'est pas une version incrémentale de JUnit 4 : c'est une réécriture, avec un nouveau paquetage (org.junit.jupiter), un nouveau modèle d'extension et un cycle de vie explicite. La confusion la plus fréquente vient de là : org.junit.Test et org.junit.jupiter.api.Test coexistent souvent dans le même projet, et une classe annotée avec l'ancienne est tout simplement ignorée par le nouveau moteur. Elle ne casse pas, elle disparaît. Vérifiez toujours le nombre de tests exécutés après une migration.
Mise en place
Avec Maven, une seule dépendance suffit ; le surefire récent détecte JUnit 5 sans configuration.
Commentaires
Les commentaires sont alimentés par GitHub Discussions
Connectez-vous avec GitHub pour participer à la discussion