En effet, dans ce contexte, les tests obligent le développeur à suivre de manière plus formelle les préceptes de base de la programmation orientée objet regroupés sous l’acronyme SOLID.

Les tests écrits dans le cadre du TDD sont donc, en plus d’être un signal d’alarme en cas de problème, des indicateurs qui indiquent au développeur le chemin à suivre pour écrire un code plus lisible et plus facile à réutiliser, maintenir et à faire évoluer.

Si les tests n’améliorent pas la qualité du code, ils permettent donc cependant au développeur qui les rédige de le faire tel un guide de haute montagne montrant à l’alpiniste pourtant chevronné le chemin à la fois le plus efficace et le plus sécurisé lui permettant d’atteindre le sommet de la montagne de la manière la plus sure.

Car malgré son expérience et son intelligence, le développeur reste tout de même un être humain et il est donc par nature faillible et surtout fainéant.

Il est en donc parfois pour lui très tentant d’emprunter des raccourcis ou de prendre des chemins de traverse, car à première vue le chemin à parcourir pour atteindre l’objectif sera plus facile, plus rapide ou moins fastidieux.

Il oublie alors les bonnes pratiques, car il ne veut pas prendre le temps de faire les choses correctement, non pas parce qu’il ne veut pas faire bien son travail, mais parce qu’il a la pression de sa hiérarchie ou bien parce qu’il pense que cela sera sans conséquence, oubliant par la même le sacro-saint précepte de Edward Aloysius Murphy.

Ou bien alors, il pense tout simplement qu’il n’a pas forcément besoin de suivre le chemin plus fastidieux imposé par le respect de SOLID pour obtenir le résultat voulu : peu importe la forme, l’important est que ça fonctionne.

Or, les tests ne permettent pas cela, car un code écrit de cette façon devient très difficile à tester, et c’est d’ailleurs souvent ce qui les rend si détestable aux yeux des développeurs.

D’ailleurs, un bon indicateur empirique de la qualité d’un code est la facilité d’écriture des tests associés.

Si ces derniers sont simples à rédiger, alors il y a de fortes chances que le code correspondant soit de qualité.

Dans le cas contraire, c’est un indicateur très fort de la nécessité d’une refonte de l’architecture du code.

Arrivé à ce point de mes réflexions, j'ai réalisé que le mot indicateur y revient régulièrement, et j'en suis donc arrivé à la conclusion que les tests sont donc de mon point de vue en tout point similaire à la signalisation routière.

En effet, tout comme les tests pour le développeur, certains panneaux routiers indiquent au conducteur la direction à suivre parmi tous les chemins possibles pour arriver correctement à destination, tandis que d’autres l’avertissent d’un danger plus ou moins imminent ainsi que sur sa nature.

Et tout comme un test ne peut vérifier que les comportements pour lesquels il a été conçu, les radars routiers sont capables de détecter automatiquement de par leur conception uniquement certaines infractions spécifiques et ignore totalement toutes les autres.

Pour la gestion de ces dernières, l’intervention humaine sous la forme d’un humain coiffé d’un képi reste incontournable, tout comme le travail en binôme, la revue de code et la recette manuelle sont incontournables pour le développeur même lorsqu’il met en œuvre des tests automatisés.

De là à dire que le développement revient à arpenter un chemin semé d’embuches diverses que les tests nous permettent plus ou moins d’anticiper efficacement…