Pour ses développements, l’équipe documentaire s’efforce de mettre en place une méthode de tests systématiques.
Pourquoi cela ? Et comment procédons-nous ?
L’intérêt des tests automatisés dans le cadre d’applications métier qui vont évoluer et être maintenues pendant des années n’est plus à démontrer :
- ils documentent les fonctionnalités métier de manière pratique et complète, et facilitent ainsi la rotation des développeurs et la capacité à intervenir sur du code qui n’est pas le sien,
- ils limitent les régressions fonctionnelles, toujours très mal supportées par les utilisateurs,
- ils encouragent des architectures de code maintenables : le découplage par exemple
Cela fait quelque temps que la pratique est encouragée dans nos équipes de développement, avec un suivi au niveau de l’intégration continue ou de notre plateforme qualité sonarqube. Et nous avons, comme d’autres, constaté certaines difficultés avec nos jeux de tests. En particulier s’assurer de ne pas oublier de tester certaines fonctionnalités essentielles, et surtout être sûr que nos tests sont bien écrits et vont vraiment nous avertir si le code applicatif dérive dans le futur. Ce second point est beaucoup plus difficile qu’il n’y paraît et la seule assurance (au moins à court terme) reste de changer le code applicatif pour voir le test planter avant de le remettre en place, ce qui est évidemment chronophage et insatisfaisant.
Depuis quelque temps, nous expérimentons le développement piloté par les tests ou test driven development. Le principe consiste à ne pas écrire de nouveau code applicatif tant qu’on n’a pas au moins un test en échec. Dit autrement, on ne change pas le code tant qu’on n’a pas un test qui prouve la nécessité de le changer. Le processus d’écriture d’une nouvelle fonctionnalité va donc être le suivant :
- écrire un test, qui doit être en échec : on se donne ainsi une chance que le test soit bien écrit et puisse nous alerter dans le futur si la fonctionnalité régresse,
- écrire le code applicatif le plus simple possible (c’est important !) pour que l’ensemble des tests déjà écrits passent. Il faut ici éviter d’anticiper sur les futurs tests pas encore écrits pour pouvoir les vérifier en erreur eux-aussi lors de leur écriture.
- Une fois que l’ensemble du jeu de tests existant passe, on peut procéder au remaniement du code applicatif existant.
Ce nouveau mode d’écriture de code répond assez directement aux deux problématiques visées. Et nous avons pu constater par ailleurs, ce que nous n’avions pas forcément envisagé, qu’il encourage une architecture de code plus simple en insistant sur les petits pas progressifs plutôt que sur l’usine à gaz qui anticipe souvent des besoins qui ne viendront jamais.
S’il est relativement facile à mettre en place lorsque les fonctionnalités sont assez bien balisées, il est parfois difficile à mettre en place lors d’expérimentations fonctionnelles. Dans ce cas, on peut avoir tendance à repasser sur des tests a posteriori mais on constate que la pratique du TDD a quand même largement changé nos habitudes et que la vérification de ses tests en intervenant ponctuellement sur le code applicatif est devenue plus naturelle.
Schéma : source Wikipedia - Xarawn - Own work - CC BY-SA 4.0
