Notice: This page requires JavaScript to function properly.
Please enable JavaScript in your browser settings or update your browser.
Apprendre Création de Tests Unitaires | Tests Unitaires
Bibliothèque Java JUnit. Types de Tests
course content

Contenu du cours

Bibliothèque Java JUnit. Types de Tests

Bibliothèque Java JUnit. Types de Tests

1. Tests en Développement
2. Tests Unitaires
3. Exceptions

book
Création de Tests Unitaires

Commençons par un peu de pratique concrète et commençons enfin à écrire des tests unitaires en utilisant la bibliothèque JUnit. Nous allons tester la méthode pas si complexe filterAndSortPalindromes, qui renvoie uniquement les chaînes qui sont des palindromes (se lisent de la même manière à l'endroit et à l'envers) et les trie ensuite par length dans l'ordre décroissant. Une classe avec une telle méthode ressemblera à ceci :

Remarque

Veuillez noter que dans ce cours, nous utiliserons exclusivement un STYLE fonctionnel de test, que nous réaliserons en utilisant les tests unitaires.

Ici, nous utilisons l'API Stream pour traiter une liste de chaînes. Nous avons également écrit une méthode supplémentaire, isPalindrome, qui vérifie si une chaîne est un palindrome. Ensuite, nous trions les chaînes par ordre décroissant de leur longueur pour obtenir des informations structurées.

Cependant, ce qui nous intéresse, ce n'est pas le fonctionnement de cette méthode elle-même, mais son test.

Tout d'abord, nous devons créer un fichier de test pour cette méthode, et cela se fait comme suit :

La première chose que vous pouvez remarquer est l'annotation "@Test". Nous utilisons cette annotation pour indiquer les méthodes qui sont des tests unitaires. Dans notre cas, la méthode filterAndSortPalindromes est marquée avec cette annotation et sert de test. Vous devriez appliquer une telle annotation à chaque méthode qui est un test unitaire.

Ce qui nous intéresse, c'est précisément comment nous allons le tester :

La première chose que nous devons faire est de comprendre l'algorithme des actions. C'est assez simple ici. Nous avons deux paramètres : "actual" et "expected". "actual" stockera le résultat de l'exécution de la méthode, tandis que "expected" stockera le résultat attendu de la méthode.
Par exemple, écrivons une entrée de test pour le test sous la forme d'une liste de chaînes de caractères :

Cette liste contient des chaînes, dont certaines sont des palindromes.

La méthode doit trier cette liste de manière à ce que seuls les palindromes restent dedans et les trier également par ordre décroissant de longueur. En d'autres termes, le résultat attendu après l'utilisation de la méthode est une liste : ""radar", "level", "madam"."

Créons une liste "expected" avec ces valeurs :

Ensuite, nous devons créer une liste "actual". Cette liste sera celle retournée par la méthode après qu'elle ait terminé son opération avec succès. Travailler avec cette liste est simple ; nous lui assignons simplement le résultat de la méthode exécutée avec le paramètre "input".

Maintenant, nous avons des listes pour la comparaison. Pour tester la méthode, nous avons besoin que la liste "actual" soit identique à la liste "expected". Pour y parvenir, nous pouvons utiliser la commande "assertEquals", qui compare deux objets, et s'ils sont égaux, le test réussit avec succès.

Remarque

Dans le framework JUnit, il existe de nombreuses assertions différentes, telles que "equals". Plus tard dans le cours, nous en couvrirons également certaines.

Super, le test unitaire est prêt, il ne reste plus qu'à l'exécuter :

Donc, nous avons écrit un test unitaire pour notre méthode. Mais vous vous souvenez que nous devons créer non seulement un test mais un test unitaire pour chacun des cas. Par conséquent, dans le prochain chapitre, nous allons également implémenter d'autres cas de test pour cette méthode.

Les tests unitaires ne sont pas compliqués mais peuvent être un travail chronophage car vous passez du temps à réfléchir aux cas de test et à les rédiger.

Tout était clair ?

Comment pouvons-nous l'améliorer ?

Merci pour vos commentaires !

Section 2. Chapitre 3
We're sorry to hear that something went wrong. What happened?
some-alt