Complément JAVA JUnit

Plan Motivations Tests unitaires Description de JUnit Utilisation de JUnit Bonne pratique des tests unitaires Utilisation de JUnit sous Eclipse

1 Partie 1 : Motivations

Objectif d'un projet Cahier des charges Développer une application 1 Objectif d'un projet Développer une application Qui marche Qui Répond à une demande Cas d'utilisation au début d'un projet Partie de UML Résultat de la discussion avec le client Fonctionnalités à mettre en oeuvre Lien entre ces fonctionnalités ex: faire une modification après avoir fait une sélection Scénarii d'utilisation Normaux Exceptionnels Cahier des charges

Exemple de scenarii Application Fonctionnalité Scenarii 1 Gestionnaire d'emploi du temps Modifier une salle dans un emploi du temps Choisir un créneau Inexistant Existant Arrêt Choisir une nouvelle salle Libre InExistante Occupée Modification Arrêt Arrêt

Vérifier un projet JUnit Au niveau local : Moins d'erreurs de code 1 Vérifier un projet Au niveau local : Moins d'erreurs de code Traiter avec des assertions Au niveau global : L'application se comporte bien Répond au besoin Se comporte bien pour certains cas particuliers On détecte des choses qui ne devraient jamais se produire On vérifie le comportement global avec des tests JUnit

Notion de Test Besoin de tester qu'une application 1 Notion de Test Besoin de tester qu'une application Fonctionne Répond conformément au scénarii Objectif (de manière extrême): Tester tous les scenarii et les cas de figures Un Test c'est : Quelque chose à tester Des données en entrée Un résultat attendu Un résultat obtenu à l'exécution Une validation

Test (exemple) Ex : Tester une classe compteBancaire 1 public class test { Public static void main (String args[]) compteBancaire a,b,c; a=new compteBancaire(); b=new compteBancaire(); c=new compteBancaire(); a.retrait(10); b.retrait(5000); c.retrait(-50 ); System.out.println(a+b+c); }

Test (exemple) Ex : Tester une classe compteBancaire 1 Test (exemple) Ex : Tester une classe compteBancaire public class test { Public static void main (String args[]) compteBancaire a,b,c; a=new compteBancaire(); b=new compteBancaire(); c=new compteBancaire(); a.retrait(10); b.retrait(5000); c.retrait(-50 ); System.out.println(a+b+c); } Ceci n'est pas un test Vous ne savez pas ce que vous testez Vous ne validez rien Juste un moyen de dire "j'ai testé"

"Vérifier le comportement quand on dépasse le découvert" 1 Test (exemple) Scénario testé "Vérifier le comportement quand on dépasse le découvert" Données en entrée : Compte a (avec initialement 100) Découvert autorisé de 50 Retrait de 200 Résultat attendu Retrait non effectué : Il reste 100 Résultat obtenu Retrait effectué Conclusion Test non validé

Objectif d'un projet : valider la bonne exécution des scenarii 1 Dans un projet Réponse au cahier des charges Mis en place au début du projet Tester les fonctionnalités à partir des scénarii Cas normal (scénario normal) Scénario différent (retrait impossible) Scénario exceptionnel (liste vide, ...) Cas tordus Normalement les scénarios sont censés décrire tous les cas possibles Les tester un à un Objectif d'un projet : valider la bonne exécution des scenarii

Jusqu'a présent 1 Vous utilisiez (parfois) une classe de test Avec un main Problèmes : Démarche non systématique : oubli de méthodes, de scenarii Besoin d'une application déjà fonctionnelle : pas de validation incrémentale Difficulté à détecter l'origine d'une erreur Principe Programmation objet Encapsulation des objets Les méthodes publiques peuvent être testées indépendamment Test unitaire Tester les méthodes publiques dés qu'elles sont écrites

Plan Motivations Tests unitaires Description de JUnit Utilisation de JUnit Bonne pratique des tests unitaires Utilisation de JUnit sous Eclipse

Partie 2 : tests unitaires

Motivation des tests unitaires 2 Motivation des tests unitaires Cahier des charges indépendant du codage Quelque soit le code écrit dans la méthode Écriture du test avant même d'écrire le code Commencer par les tests Permet de mettre en évidence des problèmes potentiels Permet de tester les méthodes Quand on les écrits Quand on les modifie Autant tester tout le temps Pour éviter les effets de bords Objectif : Automatiser les phases de tests indépendamment du développement

2 Définition Les tests unitaires sont des tests écrits par les développeurs en même temps que le code lui-même. Ils doivent s’exécuter automatiquement, sans aucune interprétation de la part du développeur. Ils comportent des assertions qui vérifient si le code fonctionne ou non. Écrits par les développeurs : Ils sont aptes à écrire le test à partir des squelettes des méthodes S’exécuter automatiquement Pas besoin d'écrire de code dans l'application pour lancer les tests Indépendant du développement du code de l'application Comportent des assertions une assertion est une expression booléenne décrivant une condition particulière qui doit être satisfaite pour que le test soit réussi

Idéalement Définir les profils des méthodes 2 Idéalement Définir les profils des méthodes Caractériser les différents tests nécessaires et suffisants Cycle de développement Écrire le code de certaines méthodes Cliquer sur un bouton pour lancer tous les tests Utilise une application spécifique Regarder le résultat des tests Négatif : réécrire la méthode Positif : passer à la méthode suivante Application globale validée

Intérêts des tests unitaires 2 Intérêts des tests unitaires Travailler à plusieurs Problème : Interdépendance des codes Objectif : Confiance dans le travail de l'autre Détection de bug Problème : Effets de bord Objectif : Localisation des erreurs Gérer les modifications Problème : Problème de régression Objectif : Être sur que tout ce qui est fait fonctionne encore Programmer efficacement Problème : Développer du code inutile Objectif : Se limiter à la validation des tests unitaires

Partie de l'extrême programming 2 Partie de l'extrême programming Ensemble de règles 12 commandements Certaines règles fondées sur Réactivité La recherche de l'objectif avant tout Citations "To drive out the functionality the software actually needs, rather than what the programmer thinks it probably ought to have" "Top XP teams practice "test-driven development", working in very short cycles of adding a test, then making it work", Ronald E Jeffries "So XP uses a process of continuous design improvement called Refactoring, from the title of Martin Fowler's book, "Refactoring: Improving Design of Existing Code", Ronald E Jeffries http://www.extremeprogramming.org/

Plan Motivations Tests unitaires Description de JUnit Utilisation de JUnit Bonne pratique des tests unitaires Utilisation de JUnit sous Eclipse

Partie 3 : JUNIT description

Description Générale JUnit est un outil de test unitaire pour JAVA 3 Description Générale JUnit est un outil de test unitaire pour JAVA Téléchargement à l'adresse http://www.junit.org/index.htm Framework Ensemble de classes à spécialiser Plus d'informations JUnit cookbook : http://junit.sourceforge.net/#Documentation API : http://junit.sourceforge.net/javadoc/

JUnit - Comment ca marche ? 3 JUnit - Comment ca marche ? Application Test Basé sur des Classes « jumelle » de test  Avantage : tests découplé de l'application Chaque classe applicative a une classe de test. Elles évoluent ensemble Modification de la classe de test (nouveaux tests) Implémentation des méthodes dans la classe applicative Utilisation Pas rentable de tester toutes les méthodes de toutes les classes. Tester tout ce qui peut avoir des erreurs. Class Compte void retrait() 1 Class TestCompte void testRetrait1() void testRetrait2() 2

Framework JUnit Installation ? Quelques classes 3 Framework JUnit Installation ? Librairie à ajouter à la compilation pour les classes de test Ex : Java –cp "junit-3.8.1.jar;." TestCompte Utilisation d'application dans la librairie Ex : Java –cp "junit-3.8.1.jar;." junit.awtui.TestRunner Quelques classes Implémentent interface Test Faire des tests :Classe TestCase Faire des suites de test : Classe TestSuite Si besoin, regarder API

Plan Motivations Tests unitaires Description de JUnit Utilisation de JUnit Bonne pratique des tests unitaires Utilisation de JUnit sous Eclipse

Partie 4 : JUNIT utilisation

JUnit - comment ça s'utilise ? 4 JUnit - comment ça s'utilise ? Un code source à tester Créer des classes de test Créer une batterie de tests Lancer les tests Valider les tests

Créer un code source Code source classique Par ex: 4 Pas de JUnit On peut se limiter aux squelettes public class Somme { int a; public somme(int b) // a coder } public int ajoute(int c)

Pensez vos tests 4 Exemple : Test de la méthode ajouter de somme Entier a = 10; Création d'un objet somme Entier b=5 Ajouter b Vérifier qu'on obtient 15 IMPORTANT Pensez à recenser tous les cas possibles Exemple classe comptebancaire : Retrait normal Retrait avec decouvert Retrait negatif Retrait avec decouvert non autorisé

Créer un test Utiliser la classe junit.framework.TestCase 4 Créer un test Utiliser la classe junit.framework.TestCase hériter de la classe TestCase Faire un test à partir d'un scénario Définir les données de test : methode setUp() Définir les tests : méthode à écrire Savoir quoi valider Définir la libération des ressources : methode TearDown()

Créer un test (définir une classe) 4 Créer un test (définir une classe) Hériter de la classe TestCase import junit.framework.*; public class TestSomme extends TestCase { // méthodes à (re)définir }

Créer un test (définir les données) 4 Créer un test (définir les données) Redéfinir la méthode setUp() Chaque test de cette classe commence par ces instructions mais peut etre plus complexe Connection une BD, etc ... private int a; private somme s; protected void setUp() { a=10; s=new Somme(a); }

Créer un test (définir les tests) 4 Créer un test (définir les tests) Un test Une nouvelle méthode Avec des vérifications Déclaration de la méthode Public void Commence par test Vérifications (méthodes de TestCase) assertTrue(boolean b); assertEquals(Object o1,Object o2); private int a; private somme s; //creation des données protected void setUp() { a=10; s=new Somme(a); } //test methode ajoute public void testAjoute() int result=s.ajoute(2); assertEquals(result,12);

Créer un test (libération) 4 Créer un test (libération) Redéfinir la méthode tearDown() Chaque test de cette classe finit par ces intrsuctions Libérer les ressources Memoire, connection à DB, etc ... //en theorie inutile grace au garbage collector protected void tearDown() { s=null }

4 Import junit.framework.*; class TestSomme extends TestCase{ private int a; private somme s; //creation des données protected void setUp() { a=10; s=new Somme(a); } //test methode ajoute public void testAjoute() int result=s.ajoute(2); assertEquals(result,12); //liberation protected void tearDown() s=null; public class somme { int a; public somme(int b) a=b; } public int ajoute(int c) return(a+c);

4 Créer la classe Import junit.framework.*; class TestSomme extends TestCase{ private int a; private somme s; //creation des données protected void setUp() { a=10; s=new Somme(a); } //test methode ajoute public void testAjoute() int result=s.ajoute(2); assertEquals(result,12); //liberation protected void tearDown() s=null; public class somme { int a; public somme(int b) a=b; } public int ajoute(int c) return(a+c);

Liberer les ressources 4 Créer la classe Import junit.framework.*; class TestSomme extends TestCase{ private int a; private somme s; //creation des données protected void setUp() { a=10; s=new Somme(a); } //test methode ajoute public void testAjoute() int result=s.ajoute(2); assertEquals(result,12); //liberation protected void tearDown() s=null; Créer les données Créer les tests Liberer les ressources

Utiliser un test 4 Utiliser le constructeur de classe TestCase public TestCase (String methode_name) Construit un test Le paramètre est le nom de la méthode de test Définir un constructeur utilisant le constructeur de TestCase Lancer un test A la main : Methode TestResult run() Automatiquement : Application TestRunner (cf après) public TestSomme(String s) { super(s); }

Créer une batterie de tests 4 Créer une batterie de tests Objectif Lancer automatiquement plusieurs tests en même temps Classe TestSuite 2 possibilités Ajouter méthodes de test une par une TestSuite suite= new TestSuite(); suite.addTest(new TestSomme("testAjoute")); TestResult tRes=suite.run(); Ajouter toute une classe de test TestSuite suite=new TestSuite(TestSomme.class );

Fusion de testSuite 4 Objectif Syntaxe Permet de créer des suites Permettre de réunir des batteries de tests Syntaxe Méthode addTest(Test t) Permet de créer des suites Par méthode/classe à tester Fusionner ces tests pour l'application finale TestSuite suite1,suite2,suite3; //suite2 et suite3 modifiés suite1=new TestSuite(); suite1.addTest(suite2) suite1.addTest(suite3);

Lancer une suite de tests 4 Lancer une suite de tests Définir une méthode suite() dans une classe Retourne la batterie de tests à effectuer implémentant Test Public static Test suite() Exemple Méthode appelée par l'application TestRunner Interface graphique Interface textuelle public static Test suite() { return(new TestSomme("testajoute")); }

Fonctionnement en interne 4 Fonctionnement en interne Lancer l'application TestRunner Précisez une classe de Test principale Contient méthode statique suite() TestRunner prend le retour de la methode suite() Pour chaque TestCase de la suite Execute la méthode setUp() Execute la méthode de test et vérifie les assertions Execute la méthode tearDown();

Affichage obtenu Test graphique 4 Java junit.awtui.TestRunner Ajouter classpath Choisir la classe avec la méthode suite Nombre de tests Résultat des tests Nb d'échecs Tests ayant échoués Description de l'échec

Affichage obtenu Test graphique 4 Java junit.awtui.TestRunner Ajouter classpath Choisir la classe avec la méthode suite

Affichage obtenu Test batch 4 java junit.textui.TestRunner classeDeTest

Résume 4 Écrire le profil des méthodes Penser vos tests 3. Écrire les Test Classe TestCase avec setUp(), tearDown() et test 4. Créer une batterie de tests Classe TestSuite avec addTest(String); 5. Créer une méthode suite() 6. Écrire les méthodes des classes applicatives 7. Lancer Classe TestRunner avec ....

Résume 4 Écrire le profil des méthodes Penser vos tests 3. Écrire les Test Classe TestCase avec setUp(), tearDown() et test 4. Créer une batterie de tests Classe TestSuite avec addTest(String); 5. Créer une méthode suite() 6. Écrire les méthodes des classes applicatives 7. Lancer Classe TestRunner avec .... Valider et continuer

Plan Motivations Tests unitaires Description de JUnit Utilisation de JUnit Bonne pratique des tests unitaires Utilisation de JUnit sous Eclipse

Partie 5 : bonne pratique

Utilisation des test unitaires 5 Utilisation des test unitaires Vérification à chaque étape du code Permet de s'assurer que tout est toujours valide Casse pas une fonctionnalité Pas de régression du code Dés qu'un bug est détecté Un nouveau test Pour être sur que le bug ne se reproduit pas

Objectifs des tests unitaires 5 Objectifs des tests unitaires Réutilisabilité : Tests lancés à tout moment Automaticité : lancer une suite de tests très simplement l'interprétation des résultats aussi. Localisation rapide des sources d'erreurs. Code propre Pas de mélange ente les tests et le code Les tests unitaires sont implémentés dans des classes à part Différents de system.out.println() partout Documentation Les tests peuvent servir de spécification du code, et de "documentation exécutable" un nouveau développer sur une application peut savoir en lisant les tests comment se servir des objets.

Démonstration A faire

Partie 6 : sous eclipse Semaine prochaine

Rappel Eclipse est un outil !!! Outil informatique Question Ne pas oublier ce que vous venez d'apprendre Outil informatique Objectif : systèmatiser des choses Possible car il existe une structure a priori Question Qu'est ce qui est automatisable dans les tests unitaires ?

JUnit sous Eclipse

JUnit sous eclipse Objectif: Départ : Automatisation de certaines taches Départ : On écrit sa classe Eventuellement le squelette des méthodes public class siecle { public siecle() { super(); } public boolean vrai() return(false);

Création du testCase Ajouter JUnit au projet Ordre des opérations Projet  propriétés  add library  junit Ordre des opérations Sélectionner la classe Nouveau  junit TestCase Cliquer sur next Cliquer sur les méthodes à tester Finish Génère les squelettes des tests import junit.framework.TestCase; public class siecleTest extends TestCase { public void testSiecle() { fail("Not yet implemented"); // TODO } public void testVrai() {

Tester testCase Résultat Pour lancer des tests Sélectionner classe de test Contexte Run as  junit test Résultat

Créer un testSuite File  nouveau  autre  java  junit  testsuite Sélectionner les classes de test dans le testsuite

Créer un testSuite File  nouveau  autre  java  junit  testsuite Sélectionner les classes de test dans le testsuite import junit.framework.Test; import junit.framework.TestSuite; public class AllTests { public static Test suite() { TestSuite suite = new TestSuite("Test for default package"); //$JUnit-BEGIN$ suite.addTestSuite(siecleTest2.class); suite.addTestSuite(siecleTest.class); //$JUnit-END$ return suite; }

Exécuter testsuite Sélectionner la suite Run as -> junit test