Il y a peu de temps, un responsable de projets (appelons le Bernard) me faisait la remarque suivante :

Les tests sont chers, ils n'apportent une plus-value que tard dans le projet et c'est du temps perdu car ils ne sont pas vendus au client !

La question que j'aurais envie de poser à  Bernard est la suivante : "Les défauts, tu les vends au client ???" Bien sûr que non et pourtant ils coûtent bien plus chers que les tests. Donc deux points :


  1. Les tests montrent leur importance sur le long terme : ce n'est pas complètement faux si on ne regarde que les coûts de maintenance qui ont été générés par la correction des erreurs que des tests auraient éliminé tès rapidement. Seulement on oublie quelques aspects fondamentaux des tests (et du TDD par extension) : la confiance générée au sein de l'équipe entre les membres, le rythme qui est insufflé par l'écriture des tests (on évite de se perdre dans le code pendant des heures en oubliant pourquoi on le fait) et une meilleure conception du code (un code testable est moins couplé et plus cohérent). Les gains sont donc immédiats.
  2. Les tests sont chers : c'est absolument faux (sauf si on compte avec une méthode comme COCOMO bien sûr). Les tests permettent de réduire les défauts. Deux évidences ont été mises en exergue ces dernières années : aucun développeur n'est capable de produire du code sans erreur et plus un défaut est détecté tardivement, plus il coûte cher à réparer. Nous sommes donc en présence d'un constat navrant pour le monde des développeurs et des projets : laissez une équipe sans faire de test et vous aurez une montagne de défaut très chers à corriger !


Ne pas tester pendant le codage, c'est aussi déporter le problème sur les équipes de test et de recette qui ne disposent souvent d'aucun ou peu d'outils. Ces tests là sont excessivement chers et ne doivent être réservés qu'à mesurer la conformité du logiciel par rapport aux attentes. Si une équipe de testeurs passe son temps à détecter des défauts qui auraient été résolus par les tests unitaires du développeur alors le coût supplémentaire est pharaonique et les testeurs risquent de mal faire leur travail de recettage.



En ouverture, j'aimerais poser la question suivante : faut-il vraiment chercher à vendre les tests ? La même question s'applique au refactoring, à la bonne conception, à l'intégration continue, bref à toute la qualité. Pour ma part, je pense que non. Cela fait partie de notre rôle de développeur d'utiliser les moyens nécessaires à la création d'un code maintenable, avec peu de défaut et répondant au besoin.