Contre les extrémismes coûteux (le retour)

Il y a un peu plus d’un an, j’ai écrit un article dans lequel je dénonçais les coûts générés par les intégristes des tests unitaires. Le but de cet article n’était pas de dire que les tests unitaires ne servent à rien − loin de là − mais de pointer le fait qu’une approche pragmatique est préférable à une approche systématique.

Il avait suscité quelques commentaires plutôt positifs, et une réaction très véhémente (avec l’emploi du mot « bullshit » difficile à digérer).

J’en reparle aujourd’hui pour pointer un article intéressant, écrit par David Heinemeier Hansson (créateur de RubyOnRails) et publié sur le blog de 37signals.

Son propos est assez similaire au mien : les tests unitaires, c’est bien ; le test driven development, c’est pratique ; mais chercher à couvrir 100% du code est inutile et coûteux.

Il dresse une liste de sept raisons pour lesquelles il faut se retenir de tester (de son propre aveux, sa liste manque de nuance, mais c’est pour la clarté de son propos) :

• Ne pas chercher à couvrir 100% du code.
• Si votre ratio code/test est de 1:2, ça ne sent pas bon ; s’il est de 1:3, ça pue carrément.
• Si vos tests vous prennent plus d’un tiers de votre temps, vous vous y prenez sûrement mal. Si ça vous prend plus de la moitié de votre temps, vous êtes certain de mal vous y prendre.
• Ne testez pas le comportement normal de votre ORM.
• Gardez les tests d’intégration pour valider les éléments séparés (ne pas faire de tests d’intégration sur des éléments qui peuvent être testés unitairement).
• N’utilisez pas Cucumber à moins de vivre dans le royaume merveilleux des tests-écrits-par-des-non-programmeurs (et envoyez-moi une bouteille de poussière de fée si vous y êtes).
• Ne vous forcez pas à faire du TDD sur tous vos contrôleurs, tous vos modèles et toutes vos vues (mon ratio est typiquement de 20% de code testé avant d’être écrit, 80% testé après avoir été écrit).

Il cite ensuite une remarque faite par Ken Beck (inventeur de l’extrem programming et auteur référent en TDD) en réponse à une question sur le site StackOverflow :

Je suis payé pour faire du code qui fonctionne, pas pour faire des tests, donc ma philosophie est d’écrire aussi peu de tests que nécessaire pour atteindre un certain niveau de confiance (je suspecte que ce niveau est élevé par rapport aux standards industriels, mais ce n’est peut-être que de la fierté mal placée). S’il y a un type d’erreur que je ne fais habituellement pas (comme remplir les mauvaises variables dans un constructeur), je ne le teste pas.

(je vous conseille de lire le fil complet sur StackOverflow)

Au final, mon but n’est pas de fanfaronner (l’avis de David H. Hansson ne vaut pas forcément plus que l’avis d’un autre), mais juste de répéter ce que j’ai toujours dit : Même le meilleur pattern peut devenir un anti-pattern quand il est mal utilisé ou quand il est utilisé à outrance. La réponse est rarement dans les extrêmes ; on vit dans un monde nuancé.
Et il est illusoire de ne pas prendre en compte les coûts induits par les tests − tout comme il est illusoire de ne pas prendre en compte les coûts de maintenance provenant de code non testé.