TP5 : outils de couverture de code, TDD

TP5 : outils de couverture de code, TDD
UFR IEEA
Master1 info S2
TP SVL – 2008-2009
Le but de ce TP est :
1. d’apprendre à utiliser des outils de couverture de code ;
2. de relativiser leur utilité dans une approche TDD.
Les infos sur ces outils sont sur le portail, rubrique ”documents”.
Attention : pour une utilisation en ligne de commande, bien penser à compléter la variable CLASSPATH
avec JUnit4, voire mockito si besoin. Selon la manière dont on lance les outils, il peut être utile de créer
une suite de test (au sens JUnit4) qui lance tous les tests, et pour laquelle on calcule le taux de couverture.
1
Prise en main des outils
Le but de cette prise en main est de compmrendre comment chaque outil fonctionne , en particulier
quels critères de couverture sont mis en œuvre. Vous pouvez par exemple essayer de couvrir par des tests
JUnit le code suivant :
public int methodeAvecAnd(boolean a,
public int methodeAvecIfSansElse(boolean a) {
boolean b) {
int x = 0;
if (a && b)
if (a)
return 3;
x = 5;
else return 4;
return x;
}
}
Il vous est aussi demandé de regarder le taux de couverture obtenu par vos tests dans un projet réalisé
en TDD (jeu de dé par exemple).
Les outils fonctionnent en instrumentant le bytecode chargé au lancement de la JVM (possibilité de
n’instrumenter que les sources, cad pas les librairies type JUnit et mockito, ni les tests).
1.1
Pluggin Eclipse EclEmma
Le pluggin n’est pas installé au M5, c’est à vous de le faire. Il faut commencer par modifier le proxy
de Eclipse :
– dans les ”preferences”, choisir ”general” puis ”network connections” ;
– cocher ”manual proxy configuration” ;
– renseigner pour le proxy cache-etu.univ-lille1.fr, cocher ”use this proxy server for SSL” ;
– même proxy pour ”socks proxy” ;
– pour les ports : 3128.
Ensuite pour installer le pluggin (à adapter plus ou moins à la version courante d’Eclipse) :
– Dans le menu ”Help”, sélectionner ”Software Updates” ;
– Dans l’écran ”Sopftware Update. . .”, sélectionner l’onglet ”available software”, puis cliquer sur ”add
site” ;
– Dans l’écran ”add site”, indiquer http://update.eclemma.org/, puis ”OK” ;
– Dans l’onglet ”available software”, sélectionner l’URL pour EclEmma, puis cocher ”eclemma”,
terminer par ”install” et attendre ;
– Dans l’écran ”Install”, cliquer sur ”Next” puis accepter les termes de la licence, puis terminer par
”Finish”.
– Enfin demander qu’Eclipse soit relancé. L’installation d’EclEmma se traduit par une icône supplémentaire
(”coverage”) et des entrées supplémentaires dans les menus contextuels.
Pour demander un rapport de couverture en même temps qu’on lance JUnit, depuis la classe de test
faire ”coverage as” et choisir ”JUnit test”, puis aller voir les rapports de test qui s’affichent dans une vue,
et le code source coloré en vert (couvert), rouge (non couvert) et orange (partiellement couvert).
Emma en ligne de commande Pour les inconditionnels de la ligne de commande, il est possible
d’utiliser Emma (à installer). On pourra par exemple essayer :
java emmarun -cp $CLASSPATH -r html
TP SVL
-sp src/ org.junit.runner.JUnitCore jeuDe.TestAllJeuDe
2008-2009
TP SVL
TP5 : outils de couverture de code, TDD
qui crée dans le répertoire courant un répertoire coverage et écrit dedans des rapports de couverture au
format html. Cette utilisation de la ligne de commande vérifie la couverture de beaucoup trop de classes,
à vous de chercher comment faire mieux, éventuellement en utilisant ant.
Questions
– quel est le critère de couverture appliqué par Emma ? (expliquer le code couleur vert / rouge /
orange) ;
– quelle couverture obtenez-vous pour votre projet réalisé en TDD ?
1.2
Cobertura
Cobertura propose un pluggin Maven, mais pas de pluggin Eclipse. On utilisera donc la version ligne
de commande, ce qui permet de comprendre tout ce qui se cache derrière un pluggin Eclipse. On lancera
Cobertura via un fichier de configuration build.xml pour l’outil ant. Un exemple vous est donné.
Fonctionnement de Cobertura en ligne de commande
étapes :
La couverture s’obtient en plusieurs
1. instrumentation du bytecode : écriture du bytecode instrumenté dans un répertoire à choisir ;
2. lancement des tests avec JUnit, sur le bytecode instrumenté ; sérialisation du résultat dans un fichier
cobertura.ser écrit dans le répertoire courant ;
3. écriture des rapports à partir de cobertura.ser, dans un répertoire à choisir, au format xml ou
html ; coloration des sources ;
4. éventuellement fusion de différentes sessions Cobertura pour produire un unique rapport.
Fichier de configuration build.xml La première chose à faire est de créer des répertoires pour stocker
tout ce qui est généré par Cobertura. Pour ce TP on vous propose de tout stocker dans un répertoire
coverage à placer dans le répertoire test de votre projet :
– test/coverage/instrumentedClasses : bytecode instrumenté ;
– test/coverage/testReports : rapports de test JUnit (à regarder pour voir à quoi ça ressemble) ;
– test/coverage/coverageReports : rapports de couverture au format html.
Ces répertoires sont à créér.
Le fichier build.xml est à placer dans le répertoire de votre projet, au même niveau que les répertoires
src, classes, etc. La commande ant lance une cascade de commandes :
– suppression des sorties Cobertura, JUnit et des .class applicatifs (un peu violent, peut être adapté) ;
– compilation des contenus des répertoires src et test ;
– instrumentation des sources applicatifs uniquement (src) ;
– lancement de JUnit soit sur une suite de test donnée, soit sur l’ensemble des classes *Test* du
répertoire de test (à configurer en tête de build.xml) ;
– génération des rapports de couverture.
Le fichier build.xml est configurable, à vous de le modifier pour coller à votre projet.
Questions
– quels sont les critères de couverture proposé par Cobertura ?
– quelle couverture obtenez-vous pour votre projet réalisé en TDD ?
Par la suite on utilisera Cobertura.
2
Gestionnaire de login
Un exercice récapitulatif qui couvre tous les aspects vus en cours : TDD, test en isolation, test aux
limites, couverture de code. À réaliser strictement en TDD, en surveillant régulièrement la couverture
de code avec Cobertura pour vérifier qu’elle se maintient à 100%.
2008-2009
2
Master1 info S2
TP SVL
TP5 : outils de couverture de code, TDD
On souhaite réaliser un gestionnaire de login pour les utilisateurs d’un organisme.
Un utilisateur possède un nom, un prénom (des chaı̂nes de lettres), un login (au plus 8 lettres), une
adresse mèl canonique (forme Prenom.Nom uniquement).
Le gestionnaire de login doit être capable de calculer, étant donnés un nom et un prénom :
– l’adresse mèl canonique : prénom en minuscules commençant par une majuscule suivi d’un point
suivi du nom en minuscules commençant par une majuscule ;
– le login : par défaut les 8 premières lettres du nom en minuscules ; si ce login existe déjà dans la
base alors les 7 premières lettres du nom concaténées à l’initiale du prénom en minuscules, sinon
levée d’exception si ce login appartient aussi à la base.
L’interrogation de la base de données est ramenée au minimum vital : la méthode get retourne null si
le login passé en paramètre n’est pas dans la base, l’utilisateur correspondant sinon.
public User get(String login);
Question
2008-2009
: Écrire / tester en isolation le gestionnaire de login, pas plus, pas moins.
3
Master1 info S2