L’analyse de couverture de code en Java

Il ne reste plus grand’monde pour soutenir que l’écriture de tests unitaires automatisés est une perte de temps sur un projet logiciel – la notion de dette technique entre dans les moeurs. Cette prise de conscience salutaire se heurte pourtant souvent à deux grandes catégories de difficultés :

• Le conservatisme – pour ne pas dire la stupidité – de certains chefs de projet, qui persistent à voir dans l’écriture des tests une activité contre-productive, qui servira de variable d’ajustement au moindre coup de grisou
• L’existant : quand le projet n’a pas systématisé la pratique du test dès son origine et que la multiplication des anomalies tardives le pousse à la réintroduire. Par où commencer ?

Pour le premier point, la solution passe par un effort pédagogique, ou, pour les cas désespérés, par une reconversion imposée ou un congé sabbatique.
Pour le second, il faut un peu de bon sens, et un peu d’outillage.

C’est sur le deuxième aspect qu’interviennent les outils d’analyse de couverture de code (ou « code coverage » en anglais). Dans la suite, nous verrons que ces outils ne permettent pas d’évaluer les tests unitaires d’un point de vue qualitatif, mais qu’ils peuvent en revanche apporter au bon sens un précieux appui en répondant aux questions suivantes :

• Quels sont les tests unitaires déjà en place ?
• Les tests sont-ils en phase (à jour) avec le code qu’ils testent ?
• Les fonctions critiques de l’application sont-elles couvertes par les tests ?

Quelques définitions

Pour rappel, on distingue 2 grandes catégories complémentaires de tests pour un projet logiciel :

• Test par « boîte noire » (black box testing) : les tests sont effectués sans connaissance de la structure interne et des objets manipulés par le système. On ne s’intéresse qu’aux entrées et sorties de ce système. Les tests fonctionnels ou les tests manuels par exemple, appartiennent à cette catégorie.
• Test par « boîte blanche » (white box testing) : les tests s’intéressent au fonctionnement interne du système. Ainsi, les tests unitaires manipulent les objets et éléments qui composent le système. L’analyse de couverture de code permet d’obtenir une mesure indirecte de la complétude des tests effectués à ce niveau.

La couverture de code est une mesure qui décrit le degré auquel le code source d’un programme a été testé. Ainsi c’est l’exécution de tous les tests (unitaires, fonctionnels, etc…) qui va permettre de déterminer notre mesure de couverture.

Les outils fournissant cette mesure savent déterminer quels fragments de code ou quelles méthodes ont été exécutés. La mesure (ou « métrique« ) principale est calculée en faisant le rapport du nombre de lignes de code exécutées sur le nombre de lignes total du code source : c’est la couverture de ligne (« statement coverage« ).

Plusieurs autres métriques (ou « critères« ) existent et permettent de calculer la couverture de code à différents niveau de granularité :

• Method coverage : Est-ce que toutes les méthodes ont été exécutées ?
• Branch coverage : Est-ce que les structures de contrôle (if ou while par exemple) ont été testées pour les 2 cas vrai et faux ?
• Path coverage : Est-ce que tous les chemins possibles d’exécution des fonctions d’un programme ont été exécutés ?

Les stratégies d’instrumentation

En Java, il existe plusieurs manières de déterminer quelles parties du code ont été exécutées.

On distingue 2 techniques :

• L’instrumentation des classes :
     – L’outil d’instrumentation ajoute des lignes dans le code source du programme lui permettant de détecter le code exécuté.
     – L’outil intervient directement sur le code compilé (byte-code) et ajoute ses modifications (« tracking hooks« ).
• L’utilisation des options de la JVM : il est possible d’utiliser une configuration particulière de la JVM pour utiliser des « listeners » (utilisant les interfaces JVMPI ou JVMDI, remplacés par JVMTI depuis Java 5). Ainsi certains outils de profiling utilisent un environnement d’exécution particulier permettant de détecter le code exécuté.

Les outils les plus courants utilisent la technique d’instrumentation des classes, le plus souvent au niveau byte-code. Les raisons principales en sont les suivantes :

• La surcharge à l’exécution (« runtime overhead« ) pour les classes instrumentées est comprise entre 5 et 20%. L’utilisation de profilers JVM est beaucoup plus pénalisante.
• Pas besoin du code source pour instrumenter.
• Instrumentation des jars tiers possible.
• Indépendant de la plateforme.
• Facilité de branchement de l’outil ad-hoc.

A noter que certains outils utilisent une approche complémentaire : l’instrumentation dynamique (au runtime). Par exemple Emma permet d’instrumenter les classes à la volée (on the fly) et avec l’utilisation d’un classloader modifié, d’obtenir les informations de couverture d’un programme en cours d’exécution. Hansel encapsule les tests unitaires (JUnit par exemple) dans des classes spécifiques permettant d’injecter à l’exécution (à l’aide d’un classloader modifié) le code permettant de tester la couverture.

Exemple d’utilisation avec l’outil Cobertura

Caractéristiques

• Le projet Cobertura est basé sur JCoverage :
     – Il est gratuit (licence Apache et GPL).
     – Utilise l’instrumentation du byte-code en mode déconnecté (après compilation).
• Génération de rapports en HTML ou XML :
     – Possibilité de fusion de différents rapports de couverture (merge).
     – Possibilité d’incorporer les rapports dans les outils d’intégration continue (Hudson, Cruise Control).
• Metrics :
     – Statement et branch coverage pour les classes, packages et l’ensemble d’un projet.
     – Affichage de la complexité cyclomatique du code de McCabe pour chaque classes, moyenne pour chaque package et globale pour l’ensemble du projet.
• Intégration possible en ligne de commande, dans une tâche Ant ou avec Maven.

Exemple de tâches Ant

Instrumentation des classes compilées

Cette tâche permet d’instrumenter les classes :

<cobertura-instrument todir="${instrumented.dir}">
    <ignore regex="org.apache.log4j.*" />
    <fileset dir="${classes.dir}">
        <include name="**/ui/**/*.class" />
        <exclude name="**/*Test.class" />
    </fileset>
    <fileset dir="${jars.dir}">
        <include name="domain.jar" />
    </fileset>
</cobertura-instrument>

Cobertura peut également instrumenter des archives incluses dans d’autres archives. Par exemple, des jars contenu dans le répertoire WEB-INF/lib d’un war seront instrumenté et le war sera reconstruit avec les jars instrumentés inclus.

Exécution des tests unitaires

Les parties entre [ ] sont à ajouter/modifier dans une tâche Ant JUnit classique :

<junit [fork="yes"] dir="${basedir}" failureProperty="test.failed">
	[<sysproperty key="net.sourceforge.cobertura.datafile" file="${basedir}/cobertura.ser" />]
	[<classpath location="${instrumented.dir}" />]
	<classpath location="${classes.dir}" />
	[<classpath refid="cobertura_classpath" />]
	...
</junit>

Génération du rapport

Pour générer le rapport au format HTML on utilisera le code suivant :

<cobertura-report format="html" destdir="${coveragereport.dir}" srcdir="${src.dir}" />

Un exemple de rapport HTML obtenu :

Et le détail des lignes couvertes par les tests dans le code source :

Autres fonctionnalités

Cobertura propose également une tâche, « cobertura-check », permettant de définir des seuils et de vérifier comment le code est couvert par rapport à ces seuils.

La tâche « cobertura-merge », permet de fusionner plusieurs fichiers de couverture. On peut ainsi générer des rapports globaux pour les parties client et serveur d’une application ou fusionner des données obtenues sur plusieurs sessions d’utilisation de Cobertura.

Pour chacune des opérations offertes Cobertura (instrument, report, merge, check), on peut effectuer l’appel via la ligne de commande. Par exemple :

java -cp %COBERTURA_CLASSPATH% net.sourceforge.cobertura.reporting.Main --format html --destination C:\Reports\coverage

Enfin 2 projets annexes permettent également d’intégrer Cobertura dans une configuration Maven (1 ou 2) en offrant les mêmes fonctionnalités.

Cobertura ne propose malheureusement pas de plugin d’intégration à Eclipse. Comme outil proposant les même fonctionnalités et l’intégration à Eclipse, on peut citer l’outil gratuit open source EclEmma qui est une extension de Emma cité un peu plus haut.

Comment bien utiliser l’analyse de couverture de code

Comme souvent dans l’ingénierie logicielle, l’utilisation d’une métrique de mesure de la qualité s’accompagne de son lot d’apôtres plus ou moins extrémistes. Le taux de couverture des tests n’échappe pas à cette règle, et l’on voit certains définir des objectifs quantitatifs rigides dans ce domaine. Certains affirment que le taux de couverture doit être de 100% ; d’autres, plus modestes, se contenteraient de 90%.

Dans la pratique il est difficile, voire impossible d’atteindre 100% et sur un projet conséquent ce n’est même pas pertinent de vouloir le faire. La valeur du taux de couverture n’est pas en soit une mesure pertinente de la qualité des tests.
En effet, Il est important que les équipes chargées du développement ne se focalisent pas sur un chiffre à atteindre mais plutôt sur la qualité des tests effectués. Ainsi, grâce aux informations de couverture de code, les équipes peuvent repérer et corriger rapidement les tests critiques et ne pas s’attarder à optimiser les tests concernant des parties du code moins importantes.

Brian Marick, dans « How to Misuse Code Coverage » explique de manière très claire comment bien utiliser la couverture de code dans un projet TDD (Test Driven Development). Je ne vais pas reprendre ici les points abordés, mais il est important de répéter que la mesure de couverture de code ne doit pas être une fin en soi mais un moyen d’améliorer la qualité globale du code et des tests effectués pour le valider.

Liens

• JavaRanch : Introduction to code coverage
• Brian’s Malick Testing website
• Advocating the use of code coverage
• TopCoder.com : An introduction to code coverage