Eclipse Photon propose des améliorations concernant les tests en Java : il permet notamment de définir des répertoires dédiés contenant le code des tests et propose un support de JUnit 5.1.
Cet article fait partie d’une série composée de :
- Eclipse Photon : introduction
- Eclipse Photon : Code Mining
- Eclipse Photon : améliorations dans le JDT
- Eclipse Photon : un meilleur support de Java 9 et 10
- Eclipse Photon : un meilleur support de JUnit 5 et des tests
Le support des répertoires de tests
La première étape est de créer un répertoire de source en lui donnant un nom.
Dans les paramètres » Java Build Path » du projet, les répertoires sources possèdent un nouvel attribut » Contains test sources » qui permet de préciser qu’ils contiennent des sources de test.
Pour changer la valeur de cet attribut, il suffit de le sélectionner et de cliquer sur le bouton » Toogle « .
Comme indiqué sous la forme d’une erreur dans la boîte de dialogue, le résultat de la compilation des répertoires de tests doit être dans un répertoire dédié.
Pour cela, il faut cocher la case » Allow output folders for source folders » et sélectionner le répertoire concerné dans l’option » Specific Output folder « .
Ainsi les tests peuvent être regroupés dans un répertoire dédié.
Les classes des sources n’ont pas accès aux classes de tests.
La compilation d’un projet se fait maintenant en deux étapes :
- La compilation des sources
- La compilation des tests
Cela permet aux classes de tests d’avoir accès aux classes contenues dans les sources.
Deux » Working Set » dynamiques sont proposés :
- Java Main Sources
- Java Test Sources
Ils contiennent les répertoires contenant respectivement du code source ou du code de tests selon la valeur de l’attribut » Contains test sources « . Il est alors possible de les utiliser par exemple dans un filtre.
Les dépendances de tests
Il est possible de préciser des dépendances spécifiques aux tests dans le » Build Path « . Pour les projets et les bibliothèques, il existe un attribut » Visible only for test sources » qui précise si la dépendance n’est utilisable que pour les tests.
Par défaut, les icônes des répertoires et des dépendances utilisables uniquement pour les tests sont affichés avec une icône plus sombre.
Ce comportement est configurable dans les préférences Preferences > Java > Appearance
Les projets ajoutés comme dépendances peuvent contenir des répertoires de sources et des dépendances pour les tests qui sont visibles pour la compilation et l’exécution des tests. Il est possible de les rendre invisible en utilisant l’attribut » Without test code « .
Dans ce cas, le nom du projet est décoré avec la mention » [without test code] « . Cette décoration est configurable dans les préférences Preferences > General > Appearance > Label Decorations
Si le projet est un projet Java modulaire, les dépendances de tests telles que JUnit ne peuvent pas être référencées dans le module-info.java et elles ne seront donc pas visibles à la compilation. La solution utilisée lorsque des dépendances de tests sont placées dans le classpath est que le projet en cours de compilation est automatiquement configuré pour lire l’unnamed module lors de la compilation des sources de test.
L’utilisation des répertoires de tests
Lors de l’utilisation de l’assistant pour créer un nouveau Test Case JUnit, les répertoires des sources de tests sont présélectionnés par défaut.
Dans les configurations » Run » et » Debug « , l’onglet » ClassPath » ou » Dependencies » possède une case à cocher » Exclude TestCode « , cochée par défaut pour exécuter une classe dans un répertoire de source qui ne contient donc pas de tests.
Lors de l’exécution de code Java 9 avec cette option décochée, des options sont ajoutées à la JVM pour permettre un accès à l’unnamed module.
Le support de JUnit 5.1
Dans la gestion des bibliothèques, lors de l’ajout de la bibliothèque JUnit
La version utilisée pour JUnit 5 est la version 5.1.
Des améliorations dans l’assistance
Lors de l’utilisation de l’assistant pour créer un nouveau cas de test
Si JUnit n’est pas présent, l’assistant propose de l’ajouter.
Il suffit de cliquer sur » OK » et les différents jars de JUnit 5.1 sont ajoutés au » Build Path « .
Un quick fix (Ctrl + 1) propose d’ajouter la dépendance vers JUnit 5 si une annotation est utilisée et que celle-ci n’est pas accessible.
Plusieurs templates permettent de créer des méthodes de tests avec JUnit 5.1 :
- test_jupiter pour créer une méthode de tests simple annotée avec @Test
- test_factory pour créer une méthode de tests annotée avec @TestFactory
Les méthodes statiques des classes Assertions, Assumptions, DynamicContainer et DynamicTest de JUnit 5 sont ajoutées dans les » Favorites « .
Cela permet d’utiliser l’assistant de contenu (Ctrl + espace) en indiquant uniquement le début du nom de la méthode statique.
Ou le Quick Fix
De nouvelles fonctionnalités lors de l’exécution
Dans la configuration d’exécution, il est possible de préciser les tags à inclure ou exclure pour déterminer les tests JUnit 5 à exécuter.
Une boîte de dialogue permet de saisir les tags avec la possibilité d’utiliser des opérateurs logiques
Lorsqu’une méthode assertAll() échoue, il est possible comparer les différents résultats en utilisant l’option » Compare Result » du menu contextuel.
La boîte de dialogue » Result Comparaison » permet de comparer les valeurs attendues et actuelles qui sont différentes.
Dans la vue JUnit, le nombre de cas de tests exécutés est affiché avec entre parenthèses le nombre de cas de tests non exécutés dû à l’évaluation négative d’une supposition.
Dans la vue JUnit, il est possible d’utiliser l’option » Go to File » du menu contextuel d’un cas de test pour ouvrir le fichier source du cas de test et se positionner sur la méthode correspondante.
Dans la configuration d’exécution d’une classe contenant des tests JUnit, le type des arguments des méthodes est affiché lors de la sélection de la méthode de test à exécuter.
Les informations publiées via une instance de type TestReporter de JUnit 5 passée en paramètre sont affichées dans la vue Console.
Dans la vue JUnit, l’option » Run » du menu contextuel sur une classe annotée avec @Nested permet de demander la ré-exécution des cas de tests de la classe.
Dans ce cas, les tests de la classe imbriquée sont re-exécutés.
Conlusion
Photon propose (enfin) une séparation du code de production et du code des tests ainsi qu’un meilleur support de JUnit 5.