Jusqu'à quel point dois-je tester mon code?

Publié par David Beaumier le vendredi 21 octobre 2011 à 15:49

Lorsque j'accompagne une équipe de développement, inévitablement on fini par me poser cette question (ou une variant de celle-ci): "est-ce qu'on doit vraiment avoir 100% de couverture dans nos essais unitaires?". C'est une question légitime et pertinente, mais c'est aussi une question qui sous entend que l'on n'a peut-être pas besoin de tester tout le code que l'on va écrire.

Pour répondre à la question, il faut revenir à la base et se demander pourquoi on fait des essais unitaires. Selon que les tests soient écrits avant (TDD) ou après le code d'implémentation on n'obtiend pas les mêmes bénéfices. Dans le présent cas, faisons abstraction des bénéfices offerts par le TDD et concentrons-nous sur l'essentiel: qu'est-ce que les essais unitaires sont censés prouver?

Selon Wikipedia, les essais unitaires doivent démontrer qu'une unité "fonctionne correctement en toutes circonstances". En se basant sur cette définition, comment peut-on garantir un fonctionnement conforme dans toutes les conditions si on n'a pas une couverture complète? Évidemment, on peut voir celà sous l'angle de la gestion des risques et il peut être acceptable de combler un manque de couverture unitaire par des essais intégrés plus complets. Toutefois, il s'agit d'une solution palliative qui ne fait que déplacer le mécanisme par lequel on garanti le bon fonctionnment de notre code. En plus, sachez qu'il est souvent plus simple de simuler toutes les conditions possibles au niveau unitaire que par des essais intégrés.

Évidemment, 100% de couverture ce n'est qu'une cible et rarement une équipe réussira à atteindre cette marque sur une base régulière. Ne soyez pas dogmatique et établissez plutôt une tendance de la couverture de code dans le temps et révisez-là fréquemment (à la revue de Sprint, par exemple). Si chaque fois qu'elle s'éloigne de cette cible l'équipe en profite pour se questionner sur les raisons qui font qu'elle n'a pas réussi à tester cette partie du code, il en résultera invariablement une amélioration des pratiques de conception et d'essais ce qui, en bout de piste, se traduira en un meilleur design de l'application.

En terminant, je vous invite à visionner cette vidéo qui présente le point de vue de Bob Martin au sujet de la couverture de code. Bon, j'avoue que Bob a vraiment un style bien à lui d'expliquer les chose, ce qui l'a ammené à apporter certaines clarifications dans ce second vidéo sur le sujet.

blog comments powered by Disqus

0 Comments:

Post a comment

Comments have been closed for this post.