Tests Unitaires POO Frédéric Moal année 2010/2011 1

Présentation au sujet: "Tests Unitaires POO Frédéric Moal année 2010/2011 1"— Transcription de la présentation:

1 Tests Unitaires POO Frédéric Moal année 2010/2011 1
Les outils complémentaires pour une bonne gestion du code Frédéric Moal année 2010/2011 1

2 Différents type de tests
Vérification d'un système, logiciel ou matériel, en vue de savoir s'il satisfait les exigences requises en termes de qualité. Qualité du code : Découvrir les bugs avant qu'ils ne cassent l'application. Assurer la qualité très tôt pendant le codage en utilisant des outils d'analyse dynamique (débuggeur, génération du diagramme de séquence pendant l'exécution, etc.) On a déjà vu l’utilisation d’un IDE (Eclipse) avec ses aides, la gestion des versions avec subversion. On ajoute quelques compléments de bonnes pratiques minimales pour tout développeur : La génération automatique de documentation à partir d’un code commenté La gestion des logs (STOP au system.out.println !!!) Les asserts L’utilisation devenue indispensable des tests, ici on se limite aux plus simples : les tests unitaires 2 2

3 Différents type de tests
Fonctionnalités : réaliser des tests unitaires, des tests de non-régression, des tests d'intégration, des tests de validation des composants dans l'application; Performances : Test de charge mise à l'épreuve d’une application en émulant des “vrais” utilisateurs avec un outil de génération de Charge détecter les goulots d'étranglement sur les ressources systèmes à observer (temps de réponses, occupation mémoire, etc.) Réception : Réalisé par le client (acceptance, clean-room tests) S’assurer que le cahier des charges a été respecté. On a déjà vu l’utilisation d’un IDE (Eclipse) avec ses aides, la gestion des versions avec subversion. On ajoute quelques compléments de bonnes pratiques minimales pour tout développeur : La génération automatique de documentation à partir d’un code commenté La gestion des logs (STOP au system.out.println !!!) Les asserts L’utilisation devenue indispensable des tests, ici on se limite aux plus simples : les tests unitaires 3 3

4 Les tests unitaires Test structurel (white-box test) :
L'implémentation de la classe doit être connue. Test vérifiant si le code est robuste en contrôlant son comportement avec des cas de test inattendus (cas limites). Le but de ce test est d'exécuter chaque branche du code avec différentes conditions d'entrée afin de détecter tous les comportements anormaux (test "boîte blanche"). Exemple : nombre min, max, état d'une instance, dépassement de capacité, etc. Test de validation (black-box test) : Ils s'effectuent sans connaissance de la structure interne (tests "boîte noire"). Test permettant de vérifier que les exigences fonctionnelles et techniques du cahier des charges sont respectées. Le test boîte noire vérifie la fonctionnalité de l'interface publique d'une unité. 4 4

5 Quelle catégorie de tests choisir ?
Les tests boîte blanche sont très difficiles à mettre en oeuvre tandis que les tests boîte noire peuvent être automatisés De quels outils dispose t-on en Java ? 5 5

6 Quelle catégorie de tests choisir ?
Tests structurels : assertions embarquées dans le code; Pré/post conditions d'exécution d'une instruction; issues des travaux de Tony Hoare sur les spécifications algébriques pour la preuve de programme dans les années 1960; Tests boîtes noires : Conception par contrats (design by contracts) Pré/post conditions d'appel à des objets; Assertions Java; Outil d'exécution de tests unitaires (JUnit, Rational Functional Tester, etc.); 6 6

7 Tests unitaires 7 7

8 Pourquoi JUnit ? Tests unitaires
Traces (instruction log) dans les programmes Utilisation d’un debugger (possibilité de redéfinir les expressions de test) sans avoir à recompiler les programmes Sévère limitations nécessitent un jugement humain problèmes de composition : Une seule expression exécutable à la fois avec un debugger Si une trace contient de nombreux print, perte de lisibilité 8 8

9 Le débutant… TEST… Tests embarqués dans la classe. Lancement et vérification manuels.

10 Le débutant… AIE ! Plusieurs méthodes….

11 Le débutant… Devient TRES complexe ….

12 Test dans les classes ? C’est une mauvaise pratique car elle entraîne : L'augmentation de l'entropie : plus l'interface de la classe grandit, plus le programme principal "main()" grandit (jusqu'à dépasser le code fonctionnel); Le code de production est plus important que nécessaire; Absence de sécurité (exemple: mot de passe en clair dans le programme principal compilé). … 12 12

13 Test dans les classes ? C’est une mauvaise pratique car elle entraîne : Une défaillance des tests : La méthode "main()" appartient à la classe et accède aux méthodes et membres privés. Les clients de cette classe n'ont pas ce privilège => source d'erreur; La plus petite unité à tester dans la classe est la méthode : chaque méthode doit être testées séparément pour détecter les cas d'erreur; Chaque méthode doit être testée en dépit de tests précédents défaillants afin de connaître le pourcentage de tests défaillants. … 13 13

14 Test dans les classes ? C’est une mauvaise pratique car elle entraîne : La difficulté d'automatiser le test : Il est encore nécessaire de créer un script pour passer des arguments à "main()"; Chaque classe à un programme spécifique avec son code d'initialisation et des appels à des routines spécifiques. Un système de report d'anomalies maison doit être défini. 14 14

15 JUnit origine : TDD (test-driven developpment), Xtreme programming XP, méthodes agiles Erich Gamma et Kent Beck canevas (framework) ecrit en Java open source : intégration dans Eclipse et Maven ; différences notables entre JUnit 3.8 et JUnit 4 JUnit 4 plus facile a utiliser ; JUnit 3.8 plus facile a comprendre =>connaître les 2 ! 15 15

16 JUnit un ensemble d'interfaces et de classes qui collaborent
qui ne s'utilisent pas directement c'est une application (( a trous )) qui offre la partie commune des traitements et est spécialisée par chaque utilisateur il faut implanter/spécialiser les types fournis ex : pour créer un cas de test on hérite de la classe TestCase 16 16

17 Tests unitaires Classes de JUnit 17 17

18 Classes et méthodes de test
Classe de test hérite de JUnit.framework.TestCase contient les méthodes de test peut utiliser les assertXXX sans import constructeur a paramètre String (dépend des versions) Méthodes de test publique, type de retour void le nom commence obligatoirement par test pas de paramètre, peut lever une exception contiennent des assertions 18 18

19 Ecriture d’une classe de test
Tests unitaires Ecriture d’une classe de test Classe à tester : 19 19

20 Ecriture d’une classe de test
Tests unitaires Ecriture d’une classe de test Classe de test : Création des objets qui vont interagir lors du test Code qui agit sur les objets impliqués dans le test Vérification que le résultat obtenu correspond bien au résultat attendu 20 20

21 Ecriture d’une classe de test
static void assertTrue(boolean test) méthode JUnit : vérifie que test == true et dans le cas contraire lance une exception (en fait une Error) de type AssertionFailedError L’exécuteur de tests JUnit attrape ces objets Errors et indique les tests qui ont échoué 21

22 Les méthodes assert static void assertTrue(String message, boolean test) Le message optionnel est inclus dans l’Error static void assertFalse(boolean test) static void assertFalse(String message, boolean test) vérifie que test == true assertEquals(expected, actual) assertEquals(String message, expected, actual) méthode largement surchargée: arg1 et arg2 doivent être tout deux des objets ou bien du même type primitif Pour les objets, utilise la méthode equals (public boolean equals(Object o) sinon utilise == 22

23 Les méthodes assert assertSame(Object expected, Object actual)
assertSame(String message, Object expected, Object actual) Vérifie que expected et actual référencent le même objet (==) assertNotSame(Object expected, Object actual) assertNotSame(String message, Object expected, Object actual) Vérifie que expected et actual ne référencent pas le même objet (==) assertNull(Object object) assertNull(String message, Object object) Vérifie que objet est null assertNotNull(Object object) assertNotNull(String message, Object object) Vérifie que objet n’est pas null 23

24 Les méthodes assert fail() fail(String message)
Provoque l’échec du test et lance une AssertionFailedError Utile lorsque les autres méthodes assert ne correspondent pas exactement à vos besoins ou pour tester que certaines exceptions sont bien lancées try { // appel d’une méthode devant lancer une Exception fail("Did not throw an ExpectedException"); } catch (ExpectedException e) { } 24

25 setup / tearDown méthode setUp méthode tearDown
appelée avant chaque méthode de test permet de factoriser la construction de (( l'état du monde )) méthode tearDown appelée après chaque méthode de test permet de défaire (( l'état du monde )) 25

26 Ecriture d’une classe de test
26

27 Exécution d’un test Pour exécuter un test
TestResult result = (new CounterTest("testIncrement")).run(); Pour exécuter une suite de tests TestSuite suite = new TestSuite(); suite.addTest(new CounterTest("testIncrement")); suite.addTest(new CounterTest("testDecrement")); TestResult result = suite.run(); En utilisant l’introspection TestSuite suite = new TestSuite(CounterTest.class); 27

28 Résultats d’un test JUnit propose des outils pour exécuter suite de tests et afficher les résultats Ajouter à la classe de test une méthode statique suite pour rendre une suite accessible à un "exécuteur de test" (TestRunner) : public static Test suite() { TestSuite suite = new TestSuite(); suite.addTest(new CounterTest("testIncrement")); suite.addTest(new CounterTest("testDecrement")); return suite; } Autre solution (introsepection) junit.textui.TestRunner.run(CounterTest.class); De nombreux IDE intègrent JUnit : NetBeans, Eclipse 28

29 Jouer tous les tests d’un package
TestSuite contient des objets Test Des TestCase mais aussi des TestSuite Une classe AllTest Teste toutes les suite de tests du package public class AllTests { public static Test suite() { TestSuite suite = new TestSuite("Test for default package"); suite.addTest(new TestSuite(TokenizerTest.class)); suite.addTest(new TestSuite(NodeTest.class)); suite.addTest(new TestSuite(ParserTest.class)); suite.addTest(new TestSuite(TreeTest.class)); return suite; } 29

30 Jouer tous les tests de sous-package
Dans chaque package définir une suite qui inclus les suites des sous packages public class AllTests_{ public static Test suite() { TestSuite suite = new TestSuite("All helix.* and subpackages tests"); suite.addTest(helix.edb.AllTests_.suite()); suite.addTest(helix.def.AllTests_.suite()); return suite; } 30

31 JUnit 4 Différences notables dans l ’écriture Même philosophie
utilise java 5 Même philosophie test unitaire setup/teardown … Plus souple pour l’écriture 31

32 JUnit 4 @Test Mark your test cases annotations. You don’t need to prefix your test cases with “test”. In addition, your class does not need to extend from “TestCase” class. public void addition() { assertEquals(12, simpleMath.add(7, 5)); } public void subtraction() { assertEquals(9, simpleMath.substract(12, 3)); 32

33 JUnit 4 - @Before and @After
annotations for “setup” and “tearDown” methods respectively. They run before and after every test case. @Before public void runBeforeEveryTest() { simpleMath = new SimpleMath(); } @After public void runAfterEveryTest() { simpleMath = null; 33

34 JUnit 4 – @BeforeClass and @AfterClass
annotations for class wide “setup” and “tearDown” respectively. Think them as one time setup and tearDown. They run for one time before and after all test cases. @BeforeClass public static void runBeforeClass() { // run for one time before all test cases } @AfterClass public static void runAfterClass() { // run for one time after all test cases 34

35 JUnit 4 - Exception Handling
Use “expected” paramater annotation for test cases that expect exception. Write the class name of the exception that will be thrown. @Test(expected = ArithmeticException.class) public void divisionWithException() { // divide by zero simpleMath.divide(1, 0); } 35

36 JUnit 4 - @Ignore @Ignore
annotation for test cases you want to ignore. You can add a string parameter that defines the reason of ignorance if you want. @Ignore("Not Ready to Run") @Test public void multiplication() { assertEquals(15, simpleMath.multiply(3, 5)); } 36

37 JUnit 4 - Timeout Timeout
Define a timeout period in milliseconds with “timeout” parameter. The test fails when the timeout period exceeds. @Test(timeout = 1000) public void infinity() { while (true) ; } 37

38 JUnit 4 - New Assertions New Assertions
Compare arrays with new assertion methods. Two arrays are equal if they have the same length and each element is equal to the corresponding element in the other array; otherwise, they’re not. public static void assertEquals(Object[] expected, Object[] actual); public static void assertEquals(String message, Object[] expected, Object[] actual); @Test public void listEquality() { List<Integer> expected = new ArrayList<Integer>(); expected.add(5); List<Integer> actual = new ArrayList<Integer>(); actual.add(5); assertEquals(expected, actual); } 38

39 Test Tips Code a little, test a little, code a little, test a little . . . Run your tests as often as possible, at least as often as you run the compiler ☺ Begin by writing tests for the areas of the code that you’re the most worried about . . .write tests that have the highest possible return on your testing investment When you need to add new functionality to the system, write the tests first If you find yourself debugging using System.out.println(), write a test case instead When a bug is reported, write a test case to expose the bug Don’t deliver code that doesn’t pass all the tests 39

40 Principes Integration continue – Pendant le développement, le programme marche toujours – peut être qu’il ne fait pas tout ce qui est requis mais ce qu’il fait, il le fait bien. TDD Test Driven Development :pratique qui se rattache à l’eXtreme Programming “Any program feature without an automated test simply doesn’t exist.” from Extreme Programming Explained, Kent Beck 40

41 Tests : Références www.junit.org www.extremeprogramming.org
41

42 Conclusion Outils d’aide au développement, en particulier en groupe
Javadoc : indispensable ! Gain de temps énorme pour la documentation.... Log : indispensable pour le suivit après mise en production d’un logiciel Asserts/Tests unitaires : assert moins utilisés, souvent « déportés » vers tests unitaires... Tests unitaires indispensables, exécutés en continu pendant le projet, livrés avec le produit final au client. 42