English version available

Envie de frimer quand vous lancez Eclipse le matin ? Après tout, un peu de geekitude ne pourra pas faire de mal…

Téléchargez cette image (c’est la même que celle en dessous, mais au format BMP). N’importe quelle autre image au format bitmap fera l’affaire.

Remplacez le fichier « splash.bmp » contenu dans votre répertoire Eclipse : /eclipse/plugins/org.eclipse.platform_X.Y.Z.vXYZXYZXYXZYXZYXZ/ avec la nouvelle.
C’est tout ! N’oubliez de garder un backup de l’ancienne image.

Il est possible de personnaliser Eclipse davantage en consultant la page officielle.

PS : J’ai légèrement re-travaillé l’image, mais l’originale n’est pas de moi. En bon geek qui se respecte, vous aurez bien évidemment reconnu l’Etoile Noire de Dark Vador…

Splash screen Eclipse Star Wars de Fabian Piau est mis à disposition selon les termes de la licence Creative Commons Attribution – Partage dans les Mêmes Conditions 4.0 International.

 English version available

Améliorer la couverture du code avec Emma

Dans ce nouvel 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 que je me demande comment j’ai bien pu faire sans jusqu’à présent.

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.

Présentation détaillée

Voici un exemple en images pour bien voir comment cela fonctionne. En même temps, nous allons parler du Test-driven Development.

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.

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 est lançable.

Sans surprise, le test ne passe pas.

Implémentons la méthode « convert ».

Maintenant, le test réussit.

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

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 testé est surligné en vert. Dans mon cas, tout est complètement testé.

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

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.

Relançons le test avec EclEmma.

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’oeil 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.

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

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).

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 est surlignée en jaune, elle est partiellement testée. Arrangeons le code en 2 lignes pour y voir plus clair.

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.

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).

Conclusion

Selon moi, EclEmma (Emma plus généralement pour ceux qui ne travaillent pas sous Eclipse) fait partie de la boite à outil indispensable à 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 !