Une bonne couverture pour l’hiver

Améliorer la couverture du code avec Emma

Dans cet article, je vous présente le plug-in EclEmma (contraction d'Eclipse et d'Emma), Emma est un analyseur de code Java open-source qui détermine la couverture du code. EclEmma est bien évidemment son portage sous Eclipse.

Après l'avoir utilisé pendant quelques semaines, j'avoue me demander comment j'ai pu faire sans avant.


Installation du plug-in

Tout d'abord, l'installation. Sous Eclipse, Help -> Install New Software... -> Add site. L'adresse est http://update.eclemma.org/. Après installation, Eclipse doit être redémarré.

Utilisation

Habituellement, pour lancer vos tests unitaires, j'imagine que vous sélectionnez soit un package, soit une classe de tests ou soit un test seul, puis vous faites un clic droit, Run As -> JUnit Test

Pour lancer le(s) test(s) avec EclEmma afin de vérifier la couverture correspondante, il vous suffit de faire quasiment la même chose. Vous utilisez le nouveau menu "Coverage As" au lieu du "Run As". Notez qu'il est possible d'utiliser un bouton dans l'IHM, mais je préfère le menu.

Nouveau bouton IHM

Présentation détaillée

Voici un exemple en images pour bien voir comment cela fonctionne.

Nous souhaitons implémenter la fonctionnalité suivante: la conversion d'un texte au format HTML. Rien de bien évolué donc, mais parfait pour une présentation d'EclEmma.

Nous allons créer un premier test pour tester la gestion des accents.

Un premier test

Le test ne compile même pas, nous allons implémenter juste le code qu'il faut pour qu'il compile.

Après création de la classe ConvertToHtml et de sa méthode « convert », le test peut être lancé.

Le code pour que le test compile

Sans surprise, le test ne passe pas.

Le test est en échec

Implémentons la méthode « convert ».

Le code suffisant pour passer le test

Maintenant, le test réussit.

Le test passe

Le code n'est pas parfait, nous allons faire un peu de refactoring pour l'alléger et l'améliorer.

Refactoring du code

On vérifie que le test passe toujours.

A cet instant précis, vous pouvez vous poser la question suivante : bon d'accord, je sais que le code que j'ai écrit passe le test. Mais, comment être sûr que je n'ai pas écrit trop de code, c'est-à-dire que j'ai écrit un code qui fait plus que ce que mon test lui demande...

La solution est dans EclEmma. On relance le test avec ce dernier.

Le code est couvert

Le code testé est surligné en vert. Dans mon cas, tout est complètement testé.

Le test est couvert

En plus, un tableau résumé s'affiche en bas. Le taux de couverture indiqué est de 100%.

Tableau résumé EclEmma

Bon, il faut avouer que ce n'était pas trop dur avec un exemple aussi simple, mais gardez en tête l'utilité d'un tel logiciel sur une application contenant plusieurs centaines de milliers de lignes de code avec quelques milliers de tests unitaires.

Pour le tutoriel, je vais aller à l'encontre du principe TDD et modifier le code métier sans avoir préalablement écrit mon test.

Modification du code

Relançons le test avec EclEmma.

Le code n'est plus entièrement couvert

Le taux de couverture est « tombé» (si j'ose dire) à 95%. Ce que nous avons ajouté n'est clairement pas couvert par un test unitaire. La ligne est surlignée en rouge. EclEmma nous donne tout de suite le feedback qu'il nous faut.

Un coup d'œil au tableau résumé et je sais exactement quel est le fichier concerné. Bon là, c'est moins drôle, je n'en ai que deux, ce n'était pas trop difficile à trouver.

Tableau résumé EclEmma

Sans plus attendre, nous allons ajouter le test pour tester la non-conversion d'un texte qui ne doit effectivement pas être converti.

Ajout d'un second test

J'ai profité de la phase de réflexion sur l'écriture de mon test unitaire pour améliorer mon code métier en supprimant le préfixe en sortie, et en le mettant en constante.

Je relance EclEmma... Je retrouve un taux de couverture à 100%, tout est bien testé, et mon code fait exactement ce que je veux qu'il fasse (pas plus, pas moins).

Retour à une couverture optimale

Encore une fois, à des fins pédagogiques (bien sûr), nous allons modifier le code métier sans avoir modifié les tests. Supposons que maintenant on utilise un suffixe de non-conversion. On relance EclEmma. Oh, les belles couleurs !

Une ligne à moitié couverte

Une ligne est surlignée en jaune, elle est partiellement testée. Arrangeons le code en 2 lignes pour y voir plus clair.

Explications sur une ligne à moitié couverte

Tout s'explique maintenant, on est passé dans la première partie du ET mais pas dans la seconde, car la première partie n'a pas été vérifiée.

Vous l'aurez compris, EclEmma colorise les lignes de la façon suivante :

  • Vert: la ligne est testée, un test (au moins) la vérifie.
  • Rouge: la ligne n'est pas testée, aucun test ne la vérifie, il faut donc écrire un test.
  • Jaune: la ligne est partiellement testée, elle contient du code testé et du code non testé. Pour voir exactement ce qui est testé, « cassez » la ligne en plusieurs morceaux comme j'ai fait précédemment.

EclEmma fournit deux pourcentages de couverture, celui sur le code de l'application par les tests (c'est celui-ci qu'il faudra le plus surveiller, c'est le plus important), mais aussi le taux de couverture sur les tests eux-mêmes. Ce dernier peut-être utile, car il permet de faire un bon nettoyage dans les tests en montrant les lignes qui ne sont jamais utilisées.

Enfin, si vous regardez les propriétés du projet, vous pouvez avoir un résumé de la couverture par type d'élément Java. Ces chiffres sont utiles pour le développeur, le chef de projet, et peuvent faire partie d'un livrable client.

Second tableau résumé

La configuration par défaut d'EclEmma est très suffisante. Vous pouvez paramétrer quelques options comme la personnalisation des 3 couleurs ou bien ajouter le taux de couverture dans le package explorer (comme ci-dessous).

Ajout des décorateurs de pourcentage

Conclusion

Selon moi, EclEmma (Emma plus généralement pour ceux qui ne travaillent pas sous Eclipse) fait partie de la boîte à outils indispensables à tout développeur JAVA travaillant quotidiennement avec des tests unitaires.

Il vous aidera facilement à améliorer votre taux de couverture. Autrement dit, et pour être plus réaliste, il vous montrera efficacement que vous développez plus qu'il n'en faut pour passer vos tests. Ainsi, peut-être qu'un jour, vous réussirez à atteindre un taux de couverture proche du mythique 100% (mais là... rien n'est moins sûr, car tout n'est pas testable comme on le voudrait... c'est une autre histoire... et surtout un sujet différent).

Je vous souhaite un bon test de ce logiciel sur vos tests !

5 commentaires

  1. Merci pour toutes ces info.
    Par contre je n’ai pas trouvé comment modifier la configuration d’EClEMMA.

    Merci d’avance.

  2. Je me permet de commenter ce vieux post pour dire qu’il y a bien une interface pour soumettre des jobs de test.

    En faite vous l’avez dans le lien avec lequel vous envoyez des requetes POST.

    ex : http://localhost/testswarm/addjob

    Je l’ai trouvé complètement par hasard alors que je voulais intégrer une page qui permettait justement de soumettre des jobs de tests ^^, et au lieu de tomber sur la mienne, je suis tomber la dessus. 🙂

    J’espere que cela pourra en aider plus d’un !

    Pour information j’utilise testswarm sur un serveur externe.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Captcha *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.