Tout d’abord, quelques notions de base.

Les différentes métriques de couverture de code

Je vous laisse lire l’article de Wikipedia (plus complet en EN) si ça vous intéresse, mais sachez que les principales métriques utilisées (et utiles) sont :

• couverture des instructions (!= couverture de ligne)
• couverture des branches (if/else, try/catch/finally, …)
• couverture des expression booléennes (ou conditions)

Méthodes de mesure

Pour mesurer la couverture de code en Java, il faut un moyen de détecter qu’on est passé sur telle ligne/instruction/branche et pas sur une autre. Il existe plusieurs méthodes :

• L’utilisation des API de profiling de la JVM (JVMDI/PI)
• L’instrumentation du bytecode
• L’instrumentation du code source

Passons très vite sur la première méthode. Aucun des outils de mon comparatif ne l’utilise. Son principal défaut semble être le surcoût au niveau des performances (overhead).

Reste donc les 2 méthodes d’instrumentation. L’instrumentation, c’est le fait d’enrichir le programme original avec des instructions supplémentaires. Ces instructions vont être les témoins que l’on est bien passé à cet endroit du programme. Schématiquement, pour mesurer la couverture des lignes de code, il suffit d’ajouter après chaque ligne du programme original un petit bout de code qui va dire « la ligne XXX a été exécutée ». Ce bout de code va stocker son information en mémoire ou dans un fichier, et à la fin, il suffit de collecter les données et de générer un beau rapport.

L’instrumentation du code source

L’instrumentation du code source va réellement modifier le code du programme avant de le compiler et de l’exécuter.

Exemple (schématique) :

Avant instrumentation :

Après instrumentation :

N.B. : Je ne sais pas réellement ce qui est ajouté comme code, sachant que Clover est closed-source, donc ce n’est qu’indicatif.

L’instrumentation du bytecode

L’instrumentation du bytecode consiste à manipuler le code Java compilé (le fichier .class) pour y ajouter les instructions de « trace ». Le principe est donc le même que pour l’instrumentation de code source, avec les différences suivantes :

Avantages :

• pas besoin de posséder les sources du programme (mais dans ce cas on aura que la couverture des méthodes, pas des lignes)
• pas besoin de recompiler le programme, on modifie directement le .class

Inconvénients :

• le bytecode n’est pas exactement l’image fidèle des lignes de code. Le compilateur effectue des optimisations qui peuvent rendre difficile de distinguer l’exécution de lignes de code consécutives. Si le code est compilé avec l’option debug, il est quand même possible de « deviner » la ligne de manière assez fiable

Voici idéalement ce qui devrait exister…

Les générateurs de code

Tout d’abord, il faudrait que tous les outils qui génèrent du code fasse apparaître cette annotation. Voici quelques exemples (que j’utilise quotidiennement) :

• wsdl2java et les stubs Axis2
• javacc
• Magic Draw (et tous les outils d’UML)
• XmlBeans

Je pense que je vais soumettre cette idée dans les différents bug trackers de ces outils, n’hésitez pas à faire de même de votre côté.

Les IDE

Les IDE devraient exploiter cette balise en empêchant le développeur de modifier du code marqué comme @Generated. Bien sûr, le développeur peut retirer la balise et faire des modifs custo, mais dans ce cas le code devient du code qui sera considéré comme manuel. On peut même imaginer que les générateurs de code vérifient la présence de la balise avant d’écraser le code lors de générations ultérieures.

Question subsidiaire : comment empêcher un fourbe développeur de supprimer l’annotation, faire des modifs, puis remettre l’annotation ???

Les outils d’analyse de code

C’est là que ça devient très intéressant. Dans ma société nous utilisons beaucoup d’outils de mesure de la qualité du code. Liste non exhaustive :

• PMD
• Checkstyle
• Findbugs
• Cobertura
• Et Sonar pour piloter le tout

Il est très pénible de devoir configurer chacun de ces outils pour ignorer le code généré. En effet, ce code ne doit pas rentrer dans l’analyse d’un projet, car souvent :

• Il fonctionne de manière fiable (ou alors c’est un bug du générateur, pas du projet)
• Le code généré ne respecte pas le code style du projet (donc checkstyle explose)
• La couverture du code généré par les tests n’est pas toujours intéressante

Si tout ces outils pouvaient prendre en compte l’annotation @Generated, ce serait génial.

Bonus : l’annotation @Generated permet de spécifier l’outil responsable de la génération. Par exemple @Generated(value= »axis2″). On pourrait donc finement configurer le code à ignorer en fonction du générateur.

Bonus 2 : l’annotation @Generated peut se positionner non seulement sur une classe, mais également sur une méthode, un attribut, … Donc on pourrait au sein d’une même classe distinguer le code généré du code manuel !!! Chose qui n’est actuellement pas possible de configurer dans les outils que j’utilise (en général on exclut un package complet de l’analyse).

A suivre…