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