Je me suis livré à une expérience naïve (ou pas) avec un projet sur lequel je travaille actuellement.

Et si j'essayais de supprimer tout ce que je peux sans faire passer un test au rouge ?

L'expérience interdite

J'ai donc fait une copie de mon projet et j'ai commencé mon labeur destructif. Je ne me suis donné qu'une limite : ne pas supprimer les pom.xml des projets. Hormis cela, j'avais quartier libre : le code Java, les annotations Spring MVC, les fichiers de configuration Hibernate, les pages JSP, les pages HTML, les images (très peu), le web.xml...

Environ deux heures plus tard, les tests claironnaient toujours que tout allait bien... Mais j'avais tout de même supprimé 248 fichiers (environ la moitié), 56% de la totalité du projet (en octets) étaient repartis dans le chaos électronique de mon PC et le projet dans son ensemble était aussi utile qu'un anorak dans le Sahara.

Motivations

Avant de tirer des conclusions sur ces résultats, je suppose qu'il faut que je revienne un peu sur les raisons qui m'ont poussé à faire cette expérience.

Tout d'abord, ce projet est né d'une volonté de montrer les bienfaits des pratiques d'Extreme Programming dans un contexte idéal et sans compromis. TDD est une des pierres angulaires de ces pratiques. Ecrire chaque test avant de coder permet d'éviter une dérive classique que tout développeur a déjà rencontré : le bazar ! Parce que les tests donnent le courage de changer la structure du code sans crainte d'introduire des régressions. Pour en revenir à mon projet, nous avons récemment souffert d'un bazar croissant dans la partie Web engendrant des bugs que les tests n'ont pas vu.

La deuxième raison, c'est que vendredi dernier, j'ai regardé cette vidéo de Bob Martin (dit Uncle Bob). Une claque. Une bonne claque qui remet sur le droit chemin en rappelant les règles de bases. Dont celle-ci : tout code écrit doit être justifié par un test rouge.

Digression sur les outils de couverture

A ce stade de mon billet, j'ai droit à ma sempiternelle digression. Que le lecteur qui souhaite passer son chemin ne s'en prive pas ;-)

Sur ce projet j'ai fait apparaître la couverture des tests grâce à un outil de mesure de couverture, en l'occurence Emma. La couverture mesurée par Emma sur chaque module du projet est affichée clairement dans Hudson : selon le module, la couverture du projet oscille entre 90 et 99% ! Etonnant, non ?

Pour tirer des informations valides d'un tel outil, un minimum de compréhension et de recul est requis. Pour mesurer la couverture, Emma "instrumente" le code en insérant des drapeaux qui sont levés lorsqu'un test passe par le code. Comment pourrait-il faire plus ? Un code peut donc avoir une excellente couverture sans qu'aucune assertion ne soit faite en sortie. Il est très facile de tricher avec ce genre d'outil.

Dernier point : Emma est bien sûr incapable de vérifier autre chose que du code Java et c'est en partie le drame.

La seule information valable à retirer d'une telle mesure est la suivante : les zones non couvertes ne le sont vraiment pas et les zones couvertes le sont peut-être.

Et maintenant ?

Soyons clair : la plus grosse partie de l'application que j'ai pu supprimer, c'est l'application Web. Sans le fichier web.xml déjà, un serveur d'application comme Tomcat ne peut plus rien faire. Ensuite, il y a le cas des pages JSP qui sont difficilement testables.

Mes question actuelles sont les suivantes :

  • Peut-on avoir une démarche TDD pour vérifier la sortie correcte du HTML par le serveur d'application ?
  • Tomcat, qui prend plusieurs secondes à démarrer, est-il adapté pour faire du TDD où les tests sont exécutés tout le temps ?
  • Est-ce qu'en testant les sorties des pages Web et en simulant des envois de formulaire, on fait encore des tests unitaires et pas des tests d'intégration ?
  • Est-ce que c'est important de distinguer test unitaire et test d'intégration ?

Je n'ai pas de réponse définitive à toutes ces questions et je serais très curieux d'avoir des retours d'expérience sur ces points.

Allez, pour finir, je ne résiste pas à l'envie de recopier un petit dicton glâné ici :

Si ça vaut la peine d'être construit, ça vaut la peine d'être testé.

Si ça ne vaut pas la peine d'être testé, alors pourquoi tu perds ton temps dessus ?