Découvrez quelle solution de test API est arrivée en tête dans le rapport GigaOm Radar. Obtenez votre rapport d'analyse gratuit >>

Découvrez quelle solution de test API est arrivée en tête dans le rapport GigaOm Radar. Obtenez votre rapport d'analyse gratuit >>
Aller à la section
En plus d'aider les développeurs à mettre en œuvre des tests unitaires en Java et à améliorer la vitesse de programmation, les tests JUnit offrent de nombreux avantages. Dans cet article, vous découvrirez ces avantages et pourquoi vous devriez utiliser les tests JUnit pour votre développement.
Aller à la section
Aller à la section
Une version de cet article a été publiée pour la première fois sur le Blog Oracle.
Cela fait quelques années depuis la sortie de Unité 5. Si vous n'avez pas encore commencé à l'utiliser pour vos tests de développement, vous devriez. JUnit 5 est livré avec une multitude de nouvelles fonctionnalités et améliorations qui peuvent vous faire gagner du temps et des maux de tête. Voyons comment démarrer avec JUnit 5 pour profiter des avantages des dernières technologies.
Si vous utilisez JUnit 4 depuis un certain temps, la migration des tests peut sembler une tâche ardue. La bonne nouvelle est que vous n'avez probablement pas besoin de convertir de test - JUnit 5 peut exécuter des tests JUnit 4 en utilisant le Vintage bibliothèque, vous pouvez donc simplement commencer à écrire de nouveaux tests avec JUnit 5.
Voici quatre bonnes raisons de commencer à utiliser JUnit 5:
Passer de JUnit 4 à JUnit 5 est assez simple, même si vous avez des tests JUnit 4 existants. La plupart des organisations n'ont pas besoin de convertir d'anciens JUnits en JUnit 5, sauf si de nouvelles fonctionnalités sont nécessaires.
Les tests JUnit 5 ressemblent à peu près à JUnit 4, mais il y a quelques différences dont vous devez être conscient.
JUnit 5 utilise le nouveau org.JUnit.jupiter package pour ses annotations et ses classes. Par exemple, org.JUnit.Test devient org.JUnit.jupiter.api.Test.
Votre partenaire @Tester l'annotation n'a plus de paramètres; chacun de ceux-ci a été déplacé vers une fonction. Par exemple, pour indiquer qu'un test est censé lever une exception dans JUnit 4:
Dans JUnit 5, cela a changé en:
De même, les délais d'expiration ont changé. Dans JUnit 4, ils ressemblaient à ceci:
Dans JUnit 5, les délais d'attente ressemblent à ceci:
Voici d'autres annotations qui ont changé:
Les assertions de JUnit 5 sont maintenant disponibles org.JUnit.jupiter.api.Assertions. La plupart des affirmations courantes, comme assertEquals () et assertNotNull () ont le même aspect qu'avant, mais il y a quelques différences clés:
Notez que vous pouvez continuer à utiliser les assertions de JUnit 4 dans un test JUnit 5 si vous préférez.
Les hypothèses ont été déplacées vers org.JUnit.jupiter.api.Hypothèses.
Les mêmes hypothèses existent, mais prennent désormais en charge BooléenFournisseur ainsi que les matchers Hamcrest pour correspondre aux conditions. Les lambdas peuvent être utilisés (de type exécutable) pour que le code s'exécute lorsque la condition est remplie.
Voici un exemple dans JUnit 4:
Dans JUnit 5, cela devient ceci:
Dans JUnit 4, personnaliser le framework signifiait généralement utiliser un @Courir avec annotation pour spécifier un runner personnalisé. L'utilisation de plusieurs coureurs était problématique et nécessitait généralement un chaînage ou l'utilisation d'un @Régner. Cela a été simplifié et amélioré dans JUnit 5 à l'aide d'extensions.
Par exemple, la création de tests avec le framework Spring ressemblait à ceci dans JUnit 4:
Avec JUnit 5, vous incluez l'extension Spring à la place:
Votre partenaire @ExtendWith l'annotation est répétable, ce qui signifie que plusieurs extensions peuvent être combinées facilement.
Vous peut également définir facilement nos propres extensions personnalisées en créant une classe qui implémente une ou plusieurs interfaces à partir de org.JUnit.jupiter.api.extension, puis en l'ajoutant à notre test avec @ExtendWith.
Pour convertir un test JUnit 3 ou JUnit 4 existant en JUnit 5, les étapes suivantes devraient fonctionner pour la plupart des tests:
Notez que la migration des tests paramétrés nécessitera un peu plus de refactorisation, surtout si vous avez utilisé JUnit 4 Paramétré (le format des tests paramétrés JUnit 5 est beaucoup plus proche de JUnitParams).
Jusqu'à présent, je n'ai discuté que des fonctionnalités existantes et de la façon dont elles ont changé. Mais JUnit 5 offre de nombreuses nouvelles fonctionnalités pour rendre nos tests plus descriptifs et maintenables.
Avec JUnit 5, vous pouvez ajouter le @Afficher un nom annotation aux classes et méthodes. Le nom est utilisé lors de la génération de rapports, ce qui facilite la description de l'objectif des tests ainsi que le suivi des échecs, par exemple:
Vous pouvez également utiliser un générateur de nom d'affichage pour traiter votre classe et / ou méthode de test afin de générer des noms de test dans le format de votre choix. Voir la documentation JUnit pour des détails et des exemples.
JUnit 5 a introduit de nouvelles assertions, telles que:
Les suites de tests dans JUnit 4 étaient utiles, mais les tests imbriqués dans JUnit 5 sont plus faciles à configurer et à maintenir, et ils décrivent mieux les relations entre les groupes de test, par exemple:
Dans l'examplement ci-dessus, vous pouvez voir que I utiliser une seule classe pour tous les tests liés à Myclass. I peut vérifier que la classe est instanciable dans la classe de test externe, et I utiliser une classe interne imbriquée pour tous les tests où Myclass est instancié et initialisé. Le @AvantChaque La méthode s'applique uniquement aux tests de la classe imbriquée.
Votre partenaire @DisplayNames les annotations pour les tests et les classes indiquent à la fois le but et l'organisation des tests. Cela aide à comprendre le rapport de test car vous can voir les conditions dans lesquelles le test est effectué (Vérifier MyClass avec initialisation) et ce que le test vérifie (maMéthode renvoie vrai). C'est un bon modèle de conception de test pour JUnit 5.
Le paramétrage des tests existait dans JUnit 4 avec des bibliothèques intégrées telles que JUnit4Paramétré ou des bibliothèques tierces comme JUnitParams. Dans JUnit 5, les tests paramétrés sont complètement intégrés et adoptent certaines des meilleures fonctionnalités de JUnit4Paramétré et JUnitParams, Par exemple:
Le format ressemble à JUnitParams, où les paramètres sont transmis directement à la méthode de test. Notez que les valeurs à tester peuvent provenir de plusieurs sources différentes. Ici, j'ai juste un seul paramètrer donc il est facile d'utiliser un @ValeurSource. @SourceVide et @NullSource pour indiquer que I souhaitez ajouter une chaîne vide et une valeur nulle à la liste des valeurs à exécuter avec, respectivement (et vous peut les combiner, comme ci-dessus, si vous utilisez les deux). Il existe plusieurs autres sources de valeur, telles que @EnumSource et @ArgumentsSource (un fournisseur de valeur personnalisée). Si vous avez besoin de plus d'un paramètre, vous pouvez également utiliser @SourceMéthode or @CsvSource. Consultez la documentation de JUnit 5 pour plus de détails et d'exemples.
Un autre type de test ajouté dans JUnit 5 est @Test répété, où un seul test est répété un nombre spécifié de fois.
JUnit 5 fournit le ExécutionCondition extension API pour activer ou désactiver un test ou un conteneur (classe de test) de manière conditionnelle. C'est comme utiliser @Désactivée sur un test mais il peut définir des conditions personnalisées. Il existe plusieurs conditions intégrées, telles que:
Les modèles de test ne sont pas des tests réguliers. Ils définissent un ensemble d'étapes à effectuer, qui peuvent ensuite être exécutées ailleurs en utilisant un contexte d'appel spécifique. Cela signifie que vous pouvez définir un modèle de test une fois, puis créer une liste de contextes d'appel au moment de l'exécution pour exécuter ce test avec. Trouvez plus de détails et d'exemples dans la documentation de Junit 5.
Les tests dynamiques sont comme des modèles de test: les tests à exécuter sont générés au moment de l'exécution. Cependant, alors que les modèles de test sont définis avec un ensemble spécifique d'étapes et s'exécutent plusieurs fois, les tests dynamiques utilisent le même contexte d'appel mais peuvent exécuter une logique différente. Une utilisation des tests dynamiques serait de diffuser une liste d'objets abstraits et d'effectuer un ensemble distinct d'assertions pour chacun en fonction de leurs types concrets. Pour de bons exemples, consultez la documentation de Junit 5.
JUnit 5 est une mise à jour puissante et flexible du framework JUnit. Il fournit une variété d'améliorations et de nouvelles fonctionnalités pour organiser et décrire les cas de test, ainsi que pour aider à comprendre les résultats des tests. La mise à jour vers JUnit 5 est simple et rapide: il vous suffit de mettre à jour les dépendances de votre projet et de commencer à utiliser les nouvelles fonctionnalités.