Tests Unitaires

Frédéric Moal année 2010/2011

POO

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.)

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é.

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é.

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 ?

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.);

7

Tests unitaires

8

Pourquoi JUnit ?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 debuggerSi une trace contient de nombreux print, perte de lisibilité

Test

s un

itaire

s

Le débutant…

Tests embarqués dans la classe. Lancement et vérification manuels.

TEST…

Le débutant…

AIE ! Plusieurs méthodes….

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é).

…

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.

…

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.

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 : www.junit.org 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 !

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

17

Classes de JUnitTe

sts

unita

ires

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

19

Ecriture d’une classe de test

Classe à tester :

Test

s un

itaire

s

20

Ecriture d’une classe de test Classe de test :

Création des objets qui vont interagir lors du testCode qui agit sur les objets impliqués dans le testVérification que le résultat obtenu correspond bien au résultat attendu

Test

s un

itaire

s

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é

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 primitifPour les objets, utilise la méthode equals (public boolean equals(Object o) sinon utilise ==

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

24

Les méthodes assertfail()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 Exceptionfail("Did not throw an ExpectedException");

}catch (ExpectedException e) { }

25

setup / tearDown méthode setUp 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 ))

26

Ecriture d’une classe de test

27

Exécution d’un testPour exécuter un test

TestResult result = (new CounterTest("testIncrement")).run();

Pour exécuter une suite de testsTestSuite 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);

TestResult result = suite.run();

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

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 packagepublic 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;}

}

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;}

}

31

JUnit 4 Différences notables dans l ’écriture

utilise les @tags java 5 Même philosophie

test unitaire setup/teardown …

Plus souple pour l’écriture

32

JUnit 4 - @Test @Test Mark your test cases with @Test annotations.

You don’t need to prefix your test cases with “test”. In addition, your class does not need to extend from “TestCase” class.

@Testpublic void addition() {

assertEquals(12, simpleMath.add(7, 5));}@Testpublic void subtraction() {

assertEquals(9, simpleMath.substract(12, 3));}

33

JUnit 4 - @Before and @After @Before and @After Use @Before and @After annotations for

“setup” and “tearDown” methods respectively. They run before and after every test case.

@Beforepublic void runBeforeEveryTest() {

simpleMath = new SimpleMath();}@Afterpublic void runAfterEveryTest() {

simpleMath = null;}

34

JUnit 4 – @BeforeClass and @AfterClass

@BeforeClass and @AfterClass Use @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.

@BeforeClasspublic static void runBeforeClass() {

// run for one time before all test cases}@AfterClasspublic static void runAfterClass() {

// run for one time after all test cases}

35

JUnit 4 - Exception Handling Exception Handling Use “expected” paramater with @Test

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 zerosimpleMath.divide(1, 0);

}

36

JUnit 4 - @Ignore @Ignore Put @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")@Testpublic void multiplication() {

assertEquals(15, simpleMath.multiply(3, 5));}

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) ;}

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);

@Testpublic void listEquality() {

List<Integer> expected = new ArrayList<Integer>();expected.add(5);List<Integer> actual = new ArrayList<Integer>();actual.add(5);assertEquals(expected, actual);

}

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

40

PrincipesIntegration 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

41

Tests : Références www.junit.org www.extremeprogramming.org www.developpez.com http://cruisecontrol.sourceforge.net/

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.