Tests Unitaires - JUnit
1. Présentation
JUnit est un framework open source (redistribution et code source libres) et donc entièrement gratuit.
C’est un outil extrêmement utile lors du développement d’une application (ou autres) : il permet en effet de mettre en place et d’exécuter des tests unitaires automatisables.
Mais à quoi sert un test unitaire ?
Grâce aux tests unitaires, il est possible de vérifier qu’une modification apportée à une application n’a pas impactée son bon fonctionnement. Ils permettent donc de détecter et d’éviter la dégradation d’un logiciel suite à une modification. On appelle cela « test de non-régression ».
JUnit propose d’exécuter ces tests en se basant sur les résultats attendus par le développeur. Si le résultat attendu correspond au résultat obtenu, le test est un succès. Dans le cas contraire, soit le test unitaire a mal été réalisé par le développeur, soit la modification apportée entrave l’application.
JUnit est un framework open source (redistribution et code source libres) et donc entièrement gratuit.
C’est un outil extrêmement utile lors du développement d’une application (ou autres) : il permet en effet de mettre en place et d’exécuter des tests unitaires automatisables.
Mais à quoi sert un test unitaire ?
Grâce aux tests unitaires, il est possible de vérifier qu’une modification apportée à une application n’a pas impactée son bon fonctionnement. Ils permettent donc de détecter et d’éviter la dégradation d’un logiciel suite à une modification. On appelle cela « test de non-régression ».
JUnit propose d’exécuter ces tests en se basant sur les résultats attendus par le développeur. Si le résultat attendu correspond au résultat obtenu, le test est un succès. Dans le cas contraire, soit le test unitaire a mal été réalisé par le développeur, soit la modification apportée entrave l’application.
2. Utilisation de JUnit
Il existe différentes versions de JUnit. Ici, nous traiterons une des versions la plus utilisée, JUnit3.
Nous nous baserons sur une application de conversion de devises.
Il existe différentes versions de JUnit. Ici, nous traiterons une des versions la plus utilisée, JUnit3.
Nous nous baserons sur une application de conversion de devises.
3. Test de ConvertisseurBasique
Cette application permet simplement de convertir une valeur saisie en Francs en Euros et inversement.
Voici un aperçu du code source :
Cette application permet simplement de convertir une valeur saisie en Francs en Euros et inversement.
Voici un aperçu du code source :
Afin de tester le convertisseur, il est nécessaire de créer une nouvelle classe que l’on nommera ConvertisseurBasiqueTest.
Après avoir créé la méthode testConvertisseur() (dans ConvertisseurBasiqueTest) , nous préciserons le paramètre que l’application prendra en entrée ainsi que le résultat attendu. Pour cela, nous utiliserons la méthode d’assertion assertEquals() , et ferons des tests pour le plus de cas de figures possible:
Si le nombre à convertir est nulle :
Si le nombre à convertir est nulle :
Avec le taux de conversion actuel (qui est celui utilisé par l’application):
Avec n’importe quel nombre :
Comme le résultat attendu et le résultat obtenu correspondent, le test est un succès.
4. Test de Convertisseur
Cette application possède deux classes métiers : Convertisseur et Devise.
Convertisseur permet de convertir une valeur en plusieurs devises ainsi que d’ajouter de nouvelles devises.
Devise permet de gérer une devise : elle stocke son nom et son taux de change par rapport au dollar.
Afin de tester le convertisseur, il est nécessaire de créer deux nouvelles classes que l’on nommera ConvertisseurTest et DeviseTest.
Nous ajouterons par la suite une troisième classe, ConvertisseurTestSuite.
4.1. DeviseTest
Dans cette classe, nous allons tester deux choses : le constructeur et la condition de la classe Devise.
4.1.1. testConstructeur()
Cette méthode permet de tester la construction d’un objet devise.
Pour cela, nous renseignons deux valeurs correspondants aux paramètres attendus par la classe devise lors de l’ajout d’une devise : le nom et le taux de change.
Ensuite, nous créons un objet de type devise à partir de ces paramètres.
Enfin, à l’aide de la méthode assertEquals(), nous vérifions que les paramètres renseignés correspondent bien à ceux retournés par la méthode.
Si c’est le cas, le test de testConstructeur() sera un succès.
4.1.2. testReglesMetier()
Cette méthode permet de tester la condition permettant de vérifier la taille d’une devise (trois lettres minimum).
Pour cela, un objet devise est tout d’abord initialisé.
On tente ensuite volontairement d’ajouter une devise dont le nom possède 4 caractères.
Cette méthode permet de tester la condition permettant de vérifier la taille d’une devise (trois lettres minimum).
Pour cela, un objet devise est tout d’abord initialisé.
On tente ensuite volontairement d’ajouter une devise dont le nom possède 4 caractères.
Si l’ajout est impossible, le test est un succès.
4.2. ConvertisseurTest
Dans cette classe, nous allons tester les méthodes permettant d’ajouter une devise (testAjouterDevise()) et de convertir une valeur (testConvertir()) de la classe Convertisseur.
Avant tout, nous utilisons la fonction setUp() qui sera executé avant chaque test.
Ici, nous y créerons un objet convertisseur auquel nous ajouterons une devise en euro (EUR) avec un taux de change de 1.36.
Dans cette classe, nous allons tester les méthodes permettant d’ajouter une devise (testAjouterDevise()) et de convertir une valeur (testConvertir()) de la classe Convertisseur.
Avant tout, nous utilisons la fonction setUp() qui sera executé avant chaque test.
Ici, nous y créerons un objet convertisseur auquel nous ajouterons une devise en euro (EUR) avec un taux de change de 1.36.
4.2.1. testAjouterDevise()
Cette méthode de test permet de vérifier que l’on ne puisse pas ajouter deux fois la même devise.
Pour cela, on essaye d’ajouter à l’objet convertisseur une devise qu’il contient déjà :
Cette méthode de test permet de vérifier que l’on ne puisse pas ajouter deux fois la même devise.
Pour cela, on essaye d’ajouter à l’objet convertisseur une devise qu’il contient déjà :
Si l’on ne peut pas ajouter cette devise une seconde fois, alors le test est un succès.
4.2.2. testConvertir()
Cette méthode de test permet de vérifier que la fonction convertir() fonctionne correctement.
Pour cela, on ajoute à l’objet convertisseur deux nouvelles devises (USD et GBP).
On effectue ensuite des conversions et, avec l’aide de la méthode assertEquals(), on vérifie que le résultat obtenu correspond bien au résultat attendu.
Cette méthode de test permet de vérifier que la fonction convertir() fonctionne correctement.
Pour cela, on ajoute à l’objet convertisseur deux nouvelles devises (USD et GBP).
On effectue ensuite des conversions et, avec l’aide de la méthode assertEquals(), on vérifie que le résultat obtenu correspond bien au résultat attendu.
Pour finir, on teste un autre cas de figure : les devises utilisées lors de la conversion n’ont pas été ajoutées à l’objet convertisseur.
Si la conversion est impossible, le test est un succès.
4.3. ConvertisseurTestSuite
Cette classe permet de tester toutes les classes de tests en une seule fois.
Cette classe permet de tester toutes les classes de tests en une seule fois.
5. Conclusion
Nous avons constaté lors de ce TP que les tests unitaires présentent de nombreux avantages:
- L'exécution est rapide.
- Ils sont simples à écrire.
- Ils permettent de tester n'importe qu'elle partie du code définie par le développeur: ils peuvent donc être très précis.
- Rassemblant généralement tous les cas d'utilisation possibles d'une application, ils peuvent constituer une excellente documentation.
Mais ils souffrent également de certaines limitations:
- Leur réalisation est longue, même si compensée par la qualité du travail obtenu après.
- Le choix des parties de code à tester est délicat.
- Les tests unitaires ont souvent un impact sur la structure du projet.
Nous avons constaté lors de ce TP que les tests unitaires présentent de nombreux avantages:
- L'exécution est rapide.
- Ils sont simples à écrire.
- Ils permettent de tester n'importe qu'elle partie du code définie par le développeur: ils peuvent donc être très précis.
- Rassemblant généralement tous les cas d'utilisation possibles d'une application, ils peuvent constituer une excellente documentation.
Mais ils souffrent également de certaines limitations:
- Leur réalisation est longue, même si compensée par la qualité du travail obtenu après.
- Le choix des parties de code à tester est délicat.
- Les tests unitaires ont souvent un impact sur la structure du projet.