Les freins et difficultés : pourquoi ne pas tester ?

Mille bonnes raisons de ne pas tester (et quelques mauvaises…)

Il y a des milliers de bonnes raisons de laisser les tests de côté. Pour vous en convaincre, allez discuter avec un développeur débutant (ou avec un mauvais développeur confirmé) : il vous expliquera, de manière fort argumentée et presque crédible que :

C'est inutile

Les mauvais développeurs croient souvent qu'ils sont suffisamment bons pour ne pas avoir besoin de tester leur code. En fait, c'est généralement le contraire…

C'est trop difficile

L'argument récurrent de ceux qui ne testent pas consiste généralement à dire qu'ils aimeraient bien le faire, mais qu'ils ne le peuvent pas, probablement à cause du fait qu'il serait trop compliqué de créer des jeux de test, de maintenir les cas de test, ou autre.

C'est irréaliste

D'aucuns pensent que les tests unitaires et d'intégration, c'est bien, mais seulement dans les livres. Ils pensent que c'est irréaliste de déployer de telles initiatives, ingérable à terme, et que le retour sur investissement est probablement faible.

Testeur, c'est pas mon job

En tant que développeurs, certains pensent que tester n'est pas leur affaire : n'existe-t-il pas d'équipes dédiées aux tests fonctionnels et à la recette ? Si, alors qu'elles le fasse !

D'autres idées pour ne pas tester ?

Certains sont très imaginatifs !

Vous l'aurez compris : toutes ces bonnes raisons de ne pas tester sont en fait mauvaises, et nous allons voir pourquoi.

Tester, c'est inutile

Quand on ne connait pas quelque chose et que l'on a des habitudes, la première réaction face à des méthodes un peu différentes des siennes consiste généralement à s'opposer et à dire (voire même parfois penser) que c'est inutile.

Pourtant tester son code procure d'énormes bénéfices. Pourquoi ?

• Les tests permettent d'éviter une part importante d'anomalies en production. Pas toutes, mais une part importante, dont on se gardera bien de donner la proportion ici, car aucune statistique fiable ne s'impose réellement en la matière. Pas sérieux ? Demandez à un médecin qu'il s'engage sur le pourcentage de chance que vous avez de ne pas attraper de maladie si vous mangez plus de légumes, moins de sucre et moins de gras : aucun ne le fera ! C'est mieux, on le sait, mais le chiffrer individuellement, dans le contexte d'un projet précis, n'aurait pas de sens.
• L'un des bénéfices les plus importants des tests est qu'ils permettent de mieux comprendre ce que l'on implémente. Et oui ! Écrire un cas de test pour une portion de code nécessite au préalable, de savoir parfaitement ce qu'est censée faire cette portion de code. Cela peut paraître trivial, mais faite une pause, et demandez-vous si, en tant que programmeur, vous ne vous êtes jamais trouvé dans la situation de passer des heures à résoudre un problème dont vous avez presque fini par oublier l'origine… Jamais ? ☺
• Produire du code (intelligemment) optimisé pour les tests revient généralement à produire du code de meilleure qualité, tout simplement. Nous en reparlerons plus tard, mais pour pouvoir tester correctement des modules entiers de code, il convient de structurer ces modules en suivant les bonnes pratiques du génie logiciel, comme le couplage faible, le principe DRY, etc.
• Les tests ne remplacent pas la documentation technique… mais ils la complètent intelligemment.
• Du code robuste, compatible avec les tests (nous y reviendrons) et testé unitairement est l'un des pré-requis à l'agilité. Si vous ne savez pas ce qu'est l'agilité, je vous conseille de lire cette introduction rapide aux méthodes agiles, voire de prendre un peu de temps pour lire l'ouvrage de référence d'une méthode agile : Scrum et XP depuis les tranchées.

• Enfin, soyons pragmatiques. Consultez quelques-uns des projets informatiques qui connaissent un grand succès dans le monde, et constatez par-vous même qu'ils mettent tous en œuvre des tests. Ensuite, demandez-vous pourquoi… :

  Linux

  Système d'exploitation que l'on ne présente plus, est testé unitairement (et pas seulement).

  Django

  L'un des meilleurs framework Web au monde, est testé unitairement.

  jQuery

  L'une des librairies Javascript les plus populaires du monde, est testée unitairement.

Tester, c'est trop difficile

Non, tester ce n'est pas difficile… Mais cela demande un peu d'entraînement et surtout de la méthode. Une méthode qui va d'ailleurs bien plus loin que l'écriture même des tests, mais jusqu'à la conception technique et l'implémentation du code métier.

La méprise sur les jeux de test trop difficiles à obtenir

Beaucoup de développeurs pendent que pour tester des composants, il est nécessaire d'avoir des jeux de données importants. Certains pensent qu'il est indispensable d'avoir des dumps des bases de données de production, pour disposer de nombreuses données. C'est une méprise !

Important Pour tester unitairement, il suffit d'avoir sous la main un jeu très limité de données pertinentes pour le test, c'est à dire permettant de mettre en avant le bon (ou mauvais) fonctionnement du composant.

Tests unitaires, tests d'intégration : c'est beau dans les livres

C'est l'argument de la dernière chance : après avoir compris l'importance et l'intérêt des tests, celui ou celle qui ne veut pas changer ses méthodes de travail pour intégrer cette pratique vous dira probablement qu'il est illusoire de croire que tout ceci est possible. Trop de temps passé à écrire le code de test, trop de maintenance, impossible d'avoir une couverture de test suffisante, etc.

Encore une fois, si le doute vous effleure et si vous vous dites que tout ceci fonctionne probablement bien sur de petits projets, ou au contraire que ce n'est valable qu'à partir d'une taille critique, regardez autour de vous. Parcourez GitHub : vous verrez que des projets de toutes tailles implémentent des tests, et que la quasi-totalité des projets qui sortent du lot le font.

Tester, c'est pas mon job

La question des responsabilités est souvent évoquée en matière de testing. Entre tests manuels, tests automatisés, techniques, fonctionnels, etc., la limite de responsabilité est souvent floue, et de ce flou profite ceux qui ne veulent pas tester.

Il est clair que les tests unitaires, tests d'intégration, etc. du code ne remplacent pas des tests plus « fonctionnels » (notez les guillemets), manuels et réalisés par des humains. L'un ne remplace pas l'autre, mais l'un ne va pas sans l'autre.

En résumé, dire qu'on ne teste pas unitairement son code parce qu'il y a une équipe de test et recette n'est pas recevable.