Découvrez comment la solution Parasoft Continuous Quality permet de contrôler et de gérer les environnements de test pour fournir des logiciels de haute qualité en toute confiance. Inscrivez-vous pour la démo >>
Temps de lecture : 7 minutesComprenez les bases et faites évoluer votre pratique de test unitaire comme un pro avec ce didacticiel.
Mais avant d'aller trop loin dans les JUnits, parlons un peu de qu'est-ce que les tests unitaires et les tests de régression et pourquoi ils sont importants en général. Nous aborderons de bons exemples au fur et à mesure.
Le test unitaire est une forme de test en boîte blanche, dans lequel les cas de test sont basés sur la structure interne. Le testeur choisit les entrées pour explorer des chemins particuliers et détermine la sortie appropriée. Le but des tests unitaires est d'examiner les composants individuels ou les éléments de méthodes / classes pour vérifier la fonctionnalité, en s'assurant que le comportement est comme prévu.
La portée exacte d'une «unité» est souvent laissée à l'interprétation, mais une bonne règle de base est qu'une unité contienne le moins de code qui effectue une tâche autonome (par exemple, une seule méthode ou classe). Il y a une bonne raison pour laquelle nous limitons la portée lors des tests unitaires - si nous construisons un test qui présente plusieurs aspects d'un projet, nous avons déplacé notre attention, de la fonctionnalité d'une seule méthode, à l'interaction entre différentes parties du code. Si le test échoue, nous ne savons pas pourquoi il a échoué et nous nous demandons si le point d'échec était dans la méthode qui nous intéressait ou dans les dépendances associées à cette méthode.
Complétant les tests unitaires, les tests de régression garantissent que le dernier correctif, amélioration ou correctif n'a pas interrompu les fonctionnalités existantes, en testant les modifications que vous avez apportées à votre code. Les changements de code sont inévitables, qu'il s'agisse de modifications de code existant ou d'ajout de packages pour de nouvelles fonctionnalités… votre code changera certainement. C'est dans ce changement que réside le plus grand danger, donc dans cet esprit, les tests de régression sont indispensables.
JUnit est un framework de test unitaire Java qui est l'une des meilleures méthodes de test pour les tests de régression. Un framework open-source, il est utilisé pour écrire et exécuter des tests automatisés répétables.
Comme pour toute autre chose, le cadre de test JUnit a évolué au fil du temps. Le changement majeur à noter est l'introduction d'annotations accompagnant la sortie de JUnit 4, ce qui a permis d'améliorer l'organisation et la lisibilité des JUnits. Le reste de ce billet de blog sera rédigé à partir des utilisations de Junit 4 et 5.
Alors allons-y. Voici les étapes à suivre pour configurer JUnit.
Les IDE les plus courants, tels qu'Eclipse et IntelliJ, auront déjà une intégration de test JUnit installée par défaut. Si l'on n'utilise pas d'EDI et que l'on s'appuie peut-être uniquement sur un système de construction tel que Maven ou Gradle, l'installation de Junit 4/5 est gérée via pom.xml ou build.gradle, respectivement. Il est important de noter que Junit 5 a été divisé en 3 modules, l'un d'entre eux étant un module vintage qui prend en charge l'annotation / la syntaxe de Junit 4 et 3 (bien que l'utilisation de Junit 3 soit franchement lugubre et ne se voit généralement que dans des projets beaucoup plus anciens).
Pour ajouter JUnit 4 à votre Maven, créez ce qui suit dans le pom.xml. Soyez conscient de la version:
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>4.12</version>
<scope>test</scope>
</dependency>
Pour Gradle, ajoutez ce qui suit au build.gradle:
apply plugin: 'java'
dependencies {
testCompile 'junit:junit:4.12'
}
L'ajout de JUnit 5 est un peu différent. En raison de la mode modulaire de JUnit 5, une nomenclature est utilisée pour importer tous les aspects. Si seules des classes particulières sont nécessaires, des groupes ou des artefacts individuels peuvent être spécifiés.
Pour ajouter JUnit 5 à Maven, ajoutez ce qui suit à pom.xml:
<dependency>
<groupId>org.junit</groupId>
<artifactId>junit-bom</artifactId>
<version>5.2.0</version>
<scope>test</scope>
</dependency>
Pour Gradle, ajoutez ce qui suit au build.gradle:
apply plugin: 'java'
dependencies {
implementation 'org.junit:junit-bom:5.2.0'
}
Si vous devez placer manuellement le chemin de classe pour les tests JUnit, Java a besoin du fichier jar brut, bien que cela ne soit généralement pas obligatoire. Git abrite le code pour JUnit. JUnit 4 a le pot disponible pour télécharger directement. Junit 5 (au moment où j'écris ceci) n'a pas actuellement le fichier jar prédéfini, mais on peut facilement compiler le code et générer les jars.
Maintenant que nous avons parlé un peu des tests et de la configuration de JUnit, passons à la construction et à l'exécution de ces tests. Pour illustrer au mieux la création de JUnits, nous voulons commencer par quelque chose de basique. Dans l'image d'exemple de test JUnit ci-dessous, nous avons une méthode simple (à gauche) qui convertit Fahrenheit en Celsius, et la JUnit (droite) associé à notre méthode. J'ai numéroté notre JUnit et je vais discuter de ces sections en détail ci-dessous.
Ce sont des importations pour les bibliothèques JUnit nécessaires pour tirer parti du cadre de test. Les bibliothèques importées peuvent être spécifiées jusqu'à une fonctionnalité particulière de JUnit, mais sont généralement importées avec des astérisques pour avoir accès à toutes les fonctionnalités.
Cela a le début de notre classe de test, la chose importante à prendre en compte ici est la convention de dénomination de la classe, qui suit ClassNameTest.
Ici, nous voyons notre première syntaxe spécifique à JUnit, une annotation. Les annotations sont extrêmement importantes lors de la création de JUnits. C'est ainsi que JUnit sait quoi faire avec la section de traitement du code. Dans notre cas d'exemple, nous avons une annotation @Test, qui indique à JUnit que la méthode publique void à laquelle elle est attachée peut être exécutée comme cas de test.
Il existe de nombreuses autres annotations, mais les plus courantes sont @Before (qui exécute une instruction / précondition avant @Test, public void), @After (qui exécute une instruction après @Test, public void, par exemple, réinitialisation de variables, suppression de fichiers temporaires, variables , etc.) et @Ignore (qui ignore certaines instructions pendant l'exécution du test - notez que @BeforeClass et @AfterClass sont utilisés pour exécuter des instructions avant et après tous les cas de test, public static void, respectivement).
La chose à emporter ici est à nouveau une convention de dénomination. Notez la structure, testezNom de la méthode.
Ici, nous construisons une nouvelle instance de notre objet de classe. Ceci est nécessaire pour que nous puissions appeler la méthode que nous testons sur quelque chose. Sans cette instance d'objet, nous ne pouvons pas tester la méthode.
Les variables associées à la méthode doivent être établies, nous déclarons donc ici les variables correspondant à notre méthode. Il faut leur donner des valeurs significatives (note: si un paramètre est un objet, on peut l'instancier, ou se moquer de lui), pour que notre test ait un sens.
Cette déclaration de variable pourrait être considérée comme facultative, mais cela en vaut la peine pour des raisons d'organisation et de lisibilité. Nous attribuons les résultats de notre méthode testée à cette variable, en l'utilisant au besoin pour les assertions et autres.
Les méthodes assert (qui font partie de la classe org.junit.Assert) sont utilisées pour déterminer l'état de réussite / échec des cas de test. Seules les assertions ayant échoué sont enregistrées. Comme pour les annotations, il existe de nombreuses options d'assertion. Dans notre exemple JUnit ci-dessus, nous utilisons assertEquals (attendu, réel, delta). Cela prend dans le résultat attendu, que l'utilisateur définit, le présenter, qui est le résultat de l'appel de la méthode, et le delta, qui permet d'implémenter un écart autorisé entre les valeurs attendues et réelles. Le but d'une assertion est la validation. Bien que cela ne soit pas nécessaire pour exécuter votre JUnit, le fait de ne pas ajouter d'assertions va sans doute à l'encontre de l'objectif de votre test. Sans affirmations, vous n'avez aucune vérification et tout au plus un test de fumée, qui ne donne de retour que lorsque des erreurs de test surviennent.
Choisissez votre propre aventure! Ici, nous allons examiner trois façons d'exécuter JUnits: directement à partir de la ligne de commande, à partir de l'EDI (Eclipse et IntelliJ), et en utilisant des systèmes de construction (Maven et Gradle).
Pour exécuter un JUnit directement à partir de la ligne de commande, vous avez besoin de quelques éléments: JDK sur votre chemin, fichier jar Junit brut et les cas de test. La commande est la suivante (cet exemple est pour Junit 4):
java -cp /path/to/junit.jar org.junit.runner.JUnitCore <test class name>
REMARQUE: dans un environnement professionnel, il est peu probable que l'on exécute un test manuellement à partir de la ligne de commande, sans un système de construction, mais la possibilité est là.
Pour exécuter à partir d'Eclipse, à partir de votre Explorateur de packages, localisez votre test JUnit, dans le dossier dans lequel vous l'avez désigné. Cliquez avec le bouton droit de la souris et descendez jusqu'à Exécuter en tant que test JUnit. Cela exécutera votre test et ouvrira une nouvelle fenêtre JUnit si elle n'est pas déjà ouverte.
L'exécution d'un test dans IntelliJ est très similaire à Eclipse. Dans la fenêtre Projet, recherchez test, cliquez avec le bouton droit de la souris et sélectionnez Exécuter 'testName'. Comme Eclipse, une fenêtre JUnit s'ouvrira avec les résultats du test.
Maven a simplifié l'exécution des tests. Assurez-vous que vous êtes au bon emplacement depuis votre ligne de commande et que le projet pom.xml est correctement configuré. Ensuite, vous pouvez exécuter ce qui suit pour exécuter vos JUnits:
mvn test
mvn -Dtest=TestName test
Gradle, comme maven, a simplifié l'exécution des tests.
gradlew test
gradlew -Dtest.single=testName test
REMARQUE: Maven et Gradle sont leur propre monstre - ce qui est montré ici est minimal pour couvrir les bases. Consultez leur documentation si vous souhaitez en savoir plus.
Notre exemple a parcouru un extrait de code très simple, et bien sûr, ce n'est que le début des tests unitaires. Les méthodes plus complexes appellent des bases de données ou d'autres méthodes, mais pour rassurer les fonctionnalités, nous avons besoin d'isolement, ce que nous réalisons grâce railleur. La moquerie nous aide à isoler des unités de code pour focaliser notre validation (les frameworks couramment utilisés pour se moquer sont Mockito et PowerMock). Pour en savoir plus sur les moqueries, lisez le post de mon collègue: Comment automatiser un test unitaire Java, y compris les simulations et les assertions.
Donc, si les tests unitaires sont si incroyables, pourquoi tout le monde n'est-il pas génial? Eh bien, les tests unitaires ne sont tout simplement pas faciles à mettre en œuvre. Cela prend beaucoup de temps et de compétences en développement, les développeurs ont tendance à ne pas l'apprécier beaucoup, et il faut de l'engagement et du temps pour maintenir les suites de tests.
Mais les avantages des tests unitaires sont évidents:
Il est donc utile de déployer de puissants outils de test unitaire comme Jtest Parasoft qui peut remédier à une grande partie des problèmes associés aux JUnits et faire gagner un temps précieux aux développeurs. Parasoft Jtest's Assistant de test unitaire prend la tête du temps, réduisant le temps de génération des tests JUnit en donnant à l'utilisateur un guide pour créer des tests avec des actions intuitives en un clic. La maintenabilité est gérée par des recommandations automatiques qui identifient des éléments tels que des environnements de test instables (et d'autres risques), des recommandations d'assertions, etc.
Pour en savoir plus sur la façon dont vous pouvez soulager la douleur et augmenter vos tests unitaires, téléchargez une version d'essai gratuite du Assistant de test d'unité Parasoft Jtest. C'est gratuit, facile à configurer et vous pouvez suivre tous les tutoriels ici pour démarrer efficacement.