JUnit Présentation complète de JUnit et « guide d’utilisation » en 13 transparents.

Présentation au sujet: "JUnit Présentation complète de JUnit et « guide d’utilisation » en 13 transparents."— Transcription de la présentation:

1 JUnit Présentation complète de JUnit et « guide d’utilisation » en 13 transparents.

2 Plan Généralités sur le test Présentation de Junit
Présentation du framework Codage TestRunner Situation de JUnit On se situe dans le domaine du test logiciel. La présentation concerne « un » outil permettant de structurer et d’optimiser ses tests d’application Java: JUnit. Quel est le code a développer pour gérer ses tests ? Quelle est l’interface visible de JUnit ? Comment se situe JUnit par rapport aux autres outils de test et à la « philosophie » actuelle de programmation ?

3 Le test Problématique Types d’erreurs
Place du test dans le cycle de développement Techniques de test Outils de test Problématique: Tests indispensables: pour valider, tester la robustesse… Coût et qualité des logiciels Types d’erreurs: Nombre infini ! Calcul: erreur dans une formule… Entrée/sortie: pb de communication avec l’extérieur (conversion, formatage…) Place du test dans le cycle de développement: À toutes les étapes (cf cycle en V) Avant tout développement (cf Xprogramming) => modéliser les tests en même temps que l’application Techniques de test: Boîte noire: techniques fonctionnelles Boite blanche: techniques structurelles Performance Tests unitaires: élément par élément Tests d’intégration: agencement des éléments et communication entre eux Tests de non régression Outils de test: Basés sur les spécifications => tests fonctionnels Robots de test d’IHM Automatisation des test à partir d’objectifs de test

4 Présentation Origine Objectifs
framework de test écrit en Java par E. Gamma et K. Beck open source: version 3.5 Objectifs test des applications Java faciliter la création des tests tests de non régression

5 Junit:Framework Un framework est un ensemble de classes et de collaborations entre les instances de ces classes.

6 Junit:Framework Le source d’un framework est disponible
Ne s’utilise pas directement: il se spécialise Ex: pour créer un cas de test on hérite de la classe TestCase Un framework peut être vu comme un programme à « trous » qui offre la partie commune des traitements et chaque utilisateur le spécialise pour son cas particulier.

7 Junit:Framework composite template
Pour l’écriture de tests, deux classes sont importantes: TestCase et TestSuite Autre classe: Assert En plus de ces classes on peut décharger un environnement pour exécuter les tests Dans les frameworks on utilise les patterns pour documenter. template

8 Codage (1/6) Organisation du code des tests Lancement des tests
cas de Test: TestCase setUp() et tearDown() les méthodes de test suite de Test: TestSuite Méthodes de test Cas de test Suite de Test Lancement des tests le TestRunner non régression Deux niveaus de définition des tests: Un cas de test contient: Des méthodes de test Les méthodes « setUp » et « tearDown » appellées avant et après chaque méthode de test Une suite de test peut contenir: Des cas de test D’autres suites de test Le lancement d’une suite de test ou d’un cas de test se fait par l’intermédiaire de l’interface « TestRunner » de JUnit qui donne le nom des méthodes contenant une erreur ou anomalie. L’indépendance entre le code de l’application et le code des tests permet d’exécuter facilement des tests de non régression.

9 Exemple:une classe Money
public class Money implements IMoney { private int fAmount; private String fCurrency; public Money(int amount, String currency) { fAmount= amount; fCurrency= currency; } /* Adds a money to this money. Forwards the request to the addMoney helper.*/ public IMoney add(IMoney m) { return m.addMoney(this); …

10 Codage (2/6) Codage d’un « TestCase »: déclaration de la classe:
public class MoneyTest extends TestCase { //délaration des instances private Money f14CHF; private MoneyBag fMB1; ... //contructeur public TestedClassTest(String name){ super(Name); } //setUp() et tearDown() //méthodes de test //création d’une suite de test //méthode main() } Voici le squelette d’une classe TestCase on peut définir des variables « globales » pouvant être utilisées dans toutes les méthodes de test Les méthodes setUp() et tearDown() permettent d’initialiser le contexte des tests et de le « restituer » Remarque: l’ordre d’exécution des méthodes de test n’est pas garanti Des exemples de setUp, méthode de tes et main sont donnés ensuite

11 Codage (3/6) la méthode setUp: la méthode tearDown:
protected void setUp() { //appellée avant chaque méthode de test f12CHF= new Money(12, "CHF"); fMB1= new MoneyBag(f12CHF, f7USD); …} Ces méthodes sont appelées avant ET après CHAQUE méthode de test. L’utilisation des mêmes noms d’instances dans plusieurs méthodes de test ne pose donc pas de problème par rapport à leur état initial qui peut être défini dans le setUp(). protected void tearDown { //appellée après chaque méthode de test f12CHF = null; ... }

12 Codage (4/6) les méthodes de test: caractéristiques:
nom préfixé par « test » contient une assertion public void testBagSimpleAdd() { // {[12 CHF][7 USD]} + [14 CHF] == {[26 CHF][7 USD]} Money bag[]= {new Money(26, "CHF"), new Money(7, "USD")}; MoneyBag expected= new MoneyBag(bag); assertEquals(expected, fMB1.add(f14CHF)); } … Méthode de test: Son nom est préfixée par « test » Sera appelée automatiquement à l’exécution du TestRunner Elle appartient à une classe héritant de la classe « TestCase » de JUnit Contient une « assertion » qui peut être: assert (boolean) assertEquals(Objet1, Objet2) assertNotNull(Object object) assertNotNull(String message, Object object) assertNull(Object object) assertNull(String message, Object object) assertSame(Object actual, Object expected) assertSame(String message, Object actual, Object expected) fail() fail(String message).

13 Codage (5/6) regroupement des méthodes de test: la fonction main:
public static Test suite() { TestSuite suite = new TestSuite(MoneyTest.class); return suite; } Le « TestCase » peut être exécuté directement en exécutant sa fonction main() Regroupement des méthodes de test: Les méthodes sont regroupées dans une « suite » Cela permet d’insérer un « TestCase » dans une suite de test La fonction main: Permet de lancer toutes les méthodes de test (l’ordre n’est pas toujours respecté) public static void main() { junit.awtui.TestRunner.run(MoneyTest.class); }

14 Codage (6/6) Codage d’une « TestSuite »: déclaration de la suite:
création d’une suite de test: fonction main() identique à celle d’un TestCase public class MaTestSuite extends TestCase { //... } public static Test suite { TestSuite suite = new TestSuite(); suite.addTest(newTestedClass(“testBagSimpleAdd”); suite.addTest(MoneyTest.suite()); suite.addTestSuite(MoneyTest.class) }

15 Détail d’implémentation
Pour exécuter une suite de tests, Junit peut utiliser l’introspection public TestSuite (final Class theClass){ … Method[] = theClass.getDeclaredMethods } private boolean isTestMethod(Method m) { String name= m.getName(); Class[] parameters= m.getParameterTypes(); Class returnType= m.getReturnType(); return parameters.length == 0 && name.startsWith("test") && returnType.equals(Void.TYPE); Il existe des classes Class et Method en Java, qui offrent des méthodes pour récupérer le nom d’une classe ou les paramètres d’une méthode.

16 TestRunner L’interface du TestRunner

17 Situation www.junit.org Avantages Inconvénients
Rq pratique: ajouter la localisation l’archive .jar dans CLASSPATH Avantages gratuit simple intégré à plusieurs IDE(Kawa, VisualAge…) Inconvénients documentation exploitation des résultats JUnit est intégré à plusieurs IDE: Kawa VisualAge…

18 Evolution Version 3.5 Généralisation des concepts (JXUnit…)
Philosophie Xprogramming (xprogramming.com): importance des test outils de tests indispensables JXUnit: séparation données de test/test => très intéressant, à exploiter JUnit s’inscrit dans la mouvance XP (voir principes ci-dessous) The Planning Process, sometimes called the Planning Game. The XP planning process allows the XP "customer" to define the business value of desired features, and uses cost estimates provided by the programmers, to choose what needs to be done and what needs to be deferred. The effect of XP's planning process is that it is easy to steer the project to success. Small Releases. XP teams put a simple system into production early, and update it frequently on a very short cycle. Metaphor. XP teams use a common "system of names" and a common system description that guides development and communication. Simple Design.   A program built with XP should be the simplest program that meets the current requirements. There is not much building "for the future". Instead, the focus is on providing business value. Of course it is necessary to ensure that you have a good design, and in XP this is brought about through "refactoring", discussed below. Testing. XP teams focus on validation of the software at all times. Programmers develop software by writing tests first, then software that fulfills the requirements reflected in the tests. Customers provide acceptance tests that enable them to be certain that the features they need are provided. Refactoring.   XP teams improve the design of the system throughout the entire development. This is done by keeping the software clean: without duplication, with high communication, simple, yet complete. Pair Programming. XP programmers write all production code in pairs, two programmers working together at one machine. Pair programming has been shown by many experiments to produce better software at similar or lower cost than programmers working alone. Collective Ownership. All the code belongs to all the programmers. This lets the team go at full speed, because when something needs changing, it can be changed without delay. Continuous Integration. XP teams integrate and build the software system multiple times per day. This keeps all the programmers on the same page, and enables very rapid progress. Perhaps surprisingly, integrating more frequently tends to eliminate integration problems that plague teams who integrate less often. 40-hour Week.   Tired programmers make more mistakes. XP teams do not work excessive overtime, keeping themselves fresh, healthy, and effective. On-site Customer. An XP project is steered by a dedicated individual who is empowered to determine requirements, set priorities, and answer questions as the programmers have them. The effect of being there is that communication improves, with less hard-copy documentation - often one of the most expensive parts of a software project. Coding Standard. For a team to work effectively in pairs, and to share ownership of all the code, all the programmers need to write the code in the same way, with rules that make sure the code communicates clearly. 

19 import junit.framework.TestCase;
import junit.framework.TestSuite; public class ExempleTest extends TestCase { public ExempleTest(String name) { super(name); } protected void setUp() { exemple = new Exemple(); } protected void tearDown() { exemple = null; } public void testExemple() { assert(exemple.getLastResult() == 0); } public void testFactoriel() { exemple.factoriel(4); assert(exemple.getLastResult() == 24); } private Exemple exemple; …} class Exemple { protected int lastResult; public int getLastResult() { return lastResult;} public void factoriel(int n) { int Result; Result = 1; for (int i=1;i<=n;i++) Result = Result * i; lastResult = Result;} public void min(int a, int b) { if (a>b) lastResult = b; else lastResult = a;} …}