La vie sans les tests automatisés
Aujourd’hui, beaucoup de logiciels sont développés avec pas ou peu de tests automatisés.
Il peut s’agit de système legacy conçus avant que cette pratique n’entre dans les mœurs, mais dans de nombreux cas les personnes du projet ne sont pas convaincus de la valeur de cette approche.
Il peut s’agit de logiciels de gestion, de sites web, de la majorité du noyau linux, ou de la très grande majorité des jeux vidéos.
Les approches sont variables d’un cas à l’autre, mais reposent essentiellement sur des tests manuels, effectués par les personnes qui développent ou des personnes dont c’est le travail.
Ces logiciels comportent des bugs, mais dans l’ensemble ils fonctionnent bien, ou en tout cas suffisamment bien pour être utilisés, parfois massivement.
Les dev ont bien intégré ce fonctionnement et l’utilisent sans problème particulier.
Je ne dis pas que cette approche est la meilleure, ou qu’elle est supérieure au fait d’avoir des tests automatisés, mais seulement que se passer de tests automatisés est une approche viable.
Les tests automatisés comme outil
Ma première expérience professionnelle a eu lieu sur un très gros projet utilisant massivement des tests automatisés.
Lors de gros refactoring, il n’était pas rare que la personne en charge de la modification ne puisse pas compiler son code sur son poste pendant plusieurs heures voire deux ou trois jours le temps de pouvoir tout modifier.
L’objectif était d’avoir des tests valides avant de pousser son code, mais pendant des phases de réécriture, le code en travaux ne fonctionnait pas, et on ne pouvait pas s’appuyer sur les tests automatisés : on se guidait du compilateur et de notes.
Les tests permettaient de valider un résultat et on écrivait des tests automatisés à tous les endroits possibles, mais on pouvait intervenir longuement sur du code sans utiliser les tests.
« Je ne peux pas coder s’il n’y a pas de test automatisés »
À l’inverse de cette approche, plusieurs personnes m’ont rapportés des anecdotes similaires : des jeunes devs n’ayant connus que des expériences dans des environnements avec des tests automatisés et qui ont peur de s’en passer.
Ces devs ont été formés aux tests automatisés en expliquant en boucle que les tests étaient un harnais ou une sécurité pour le code pour éviter les risques d’erreur à chaque pas de chaton, et qu’ils étaient absolument indispensable au développement si on veut aboutir à un résultat qui fonctionne.
Ils et elles sont persuadés qu’on ne peut pas développer sans tests automatisés, et ont peur d’intervenir dans ces situations.
À force de vouloir convaincre, on caricature jusqu’à mentir et on a créé des personnes qui codent avec la peur au ventre.
Créer l’insécurité
En réfléchissant à cela, j’ai réalisé que d’autres pratiques vont dans le même sens qui est celui de créer de volontairement un sentiment d’insécurité pour les bien des tests et du code.
L’une est celle de faire tourner les tests en continu pendant le développement : dès qu’on modifie du code on entre dans une zone rouge anxiogène, dont on va vouloir sortir le plus vite possible.
L’autre est de développer en TDD en se donnant un temps limité pour rédiger le code, avec la raison qu’un code long à écrire serait signe d’un mauvais design qu’il faudrait alors recommencer.
Le développement se fait alors littéralement contre la montre : faites passer les testes ou jetez votre travail.
Ces pratiques sont parfois volontaires, ou parfois imposées dans des équipes.
Conclusion
Je pense qu’utiliser la peur n’est pas une solution acceptable pour pousser les gens à faire des tests. Ce genre d’approche est indigne : de quel droit est ce qu’on inflige ça à des personnes ?
Elle va de plus à l’encontre de tout ce qu’enseigne l’agile (cet argument devrait être inutile après le précédent, mais je réalise que dans certains cas c’est bien celui-ci qui a le plus de poids).
Cela est aussi valable pour les pratiques qu’on s’impose à soi-même.
Il faut être capable d’avoir un discours sur l’apport des tests automatisés qui ne tombe pas dans la caricature, quitte à ce que cela prenne du temps et demande de se répéter.
Il faut que les personnes qui développent puissent le faire dans un environnement sécurisé quelles que soient leurs pratiques.