Les Tests Unitaires

An

tho

ny

Méd

assi

Introduction But : La qualité

Du responsable du projet au client: Tous inclus dans le processus de validation

Plus il y a de tests, meilleure est la qualité finale du produit

Les tests ont un coût non négligeable dans un projet

Trouver le juste équilibre entre:

La qualité que l’on souhaite obtenir

L’investissement nécessaire

Quand tester? Dépend du type de test

Le développeur teste au fur et à mesure grâce aux tests unitaires

Le testeur fonctionnel teste le plus tôt possible :

Application utilisable le plus rapidement possible

À éviter:

Tester une fois le développement terminé

Corriger au plus vite pour présenter quelques fonctionnalités au client (Agilité)

Eviter l’effet tunnel

Lire le Glandeur naturel et le faiseur de miracle

Les différents types de tests Les tests unitaires

Les tests d’intégration

Les tests fonctionnels

Les tests unitaires Les plus basiques

Ils apparaissent en 1er car liés à l’écriture du code

Le principe :

Permet la validation de code qui vient d’être écrit

Constitue un garde fou pour les modifications futures de ce code

Chaque modification apporte ses propres tests

+ Exécution des anciens tests afin de vérifier que le nouveau code ne modifie pas le comportement antérieur

Les tests d’intégration Vérifie que l’intégration de fonctions soit

opérationnelle, sans anomalie

Nécessite une application déployée et opérationnelle

Permet de valider des enchaînements d’actions valides

Évolution vers l’intégration continue:

Vérification à chaque modification de code de la non-régression:

Cruise Control

Jenkins

Impose une utilisation de versioning

Les tests fonctionnels Permet de valider une fonctionnalité de l’application

du point de vue de l’utilisateur

Tests effectués le plus souvent manuellement par un testeur

Valide les besoins utilisateurs

Mise en place de tests unitaires Le code d’abord:

Une fois méthode développée, mise en place de tests associés

Le test d’abord:

On écrit d’abord les tests qui valideront des comportements que l’on développera plus tard

Méthode TDD : Test Driven Development

Outils pour tests unitaires Des Framework existent dans la plupart des langages

xUnit avec x initial du langage:

Le premier pour SmallTalk : sUnit

cppUnit pour C++

cUnit pour le langage C

jsUnit pour Javascript

nUnit pour .NET

jUnit pour Java (intégré à Netbeans)

phpUnit pour PHP

…etc

Exemple Calculatrice Créer une classe Opération

Puis définir une méthode static addition et multiplication

Exemple Calculatrice Clic droit sur la classe puis :

Tools

Create Tests

Exemple Calculatrice La classe OperationsTest est créée

Elle contient les méthodes de test de chaque méthode de Operation

Exemple Calculatrice Modification de la méthode de test

Exemple Calculatrice Lancement des tests unitaires : clic droit sur la classe,

puis Test File.

Exemple Calculatrice Création du 2ème test, puis réexécution :

Bonnes pratiques Définir une classe de test par entité métier à valider

Méthodes de la classe de test doivent respecter un nommage précis, par exemple:

testNomMethodeATester

Précédé de @Test

Les annotations 1/2 @Test : c’est une méthode de test

@Before : exécutée avant chaque test. Prépare l’environnement du test

@After: exécutée après chaque test: nettoyage de l’environnement

@BeforeClass: exécutée 1 seule fois avant l’exécution de la classe de test:

Ex: Connexion BD

Les annotations 2/2 @AfterClass: exécutée 1 seule fois après que tous les tests

aient été exécutés

@Ignore: Ignore la méthode de test

@Test (expected = Exception.class):

Échoue si la méthode ne lève pas l’exception en question

@Test (timeout=100):

Échoue si la méthode met plus de 100ms à s’exécuter

Les assertions 1/2 assertsEquals([String message], expected, actual)

Teste si les 2 valeurs expected et actual sont égales.

Pour un tableau, teste la référence et non les valeurs

assertsEquals([String message], expected, actual, tolerance)

Teste si les valeurs correspondent avec une tolérance

La tolérance correspond au nombre de décimal identiques

fail(String)

Fait échouer la méthode de test

Les assertions 2/2 assertTrue(true) / assertTrue(false)

Fait échouer ou réussir un test

assertTrue([message], boolean condition) Teste le booléen

assertNull([message], object) Teste si l’objet est null

assertNotNull([message], object) Teste si l’objet n’est pas null

assertSame([String], expected, actual) Teste si les 2 variables font référence aux 2 mêmes objets

assertNotSame([String], expected, actual) Vérifie que les 2 variables font référence à 2 objets différents

Mock Objet qui simule un comportement

Objet fantaisie, Objet factice

Il peut être utilisé pour remplacer:

Un comportement non déterministe (Heure,T°)

Des états difficiles à reproduire (erreur réseau)

Initialisation longue (BD)

Objet qui n’existe pas encore

Doit avoir la même interface que l’objet qu’il simule

Cf. Outil EasyMock

Exercices Créer une classe Etudiant

Les attributs:

Son nom

Son prénom

Ses notes en Slam3 Slam4 et Slam5

Les méthodes:

1 pour calculer la moyenne

1 pour calculer l’écart entre la moyenne et 10

1 pour afficher le nom complet (Ex: Anthony Médassi)

Écrire la classe de test.

FIN Questions