Les étapes de l'apprentissage du TDD

Introduction

Depuis des années que je mets en oeuvre le TDD, ma pratique et ma vision ne cessent d'évoluer, surtout ces derniers temps en accompagnant des équipes de développement, en essayant de les aider à migrer vers la mise en place de tests unitaires, et bien sûr, l'approche TDD.

Récemment, en analysant les freins exprimés par une équipe, et en étudiant leurs difficultés, j'en suis arrivé à la conclusion que l'apprentissage du TDD se découpe en 3 étapes que je vous partage aujourd'hui.

Le "comment" et le "quoi"

J'entends par "comment" le fait de savoir comment on va répondre à un besoin, quelle solution on va implémenter, quel architecture et quels algorithmes on va mettre en place.

Le "quoi" correspond à ce que l'on doit obtenir, au résultat, à la fonctionnalité qu'on doit implémenter, au besoin utilisateur qu'on doit satisfaire.

Je me suis rendu compte que les développeurs se polarisent sur le "comment" au lieu du "quoi", et pas seulement pour les tests unitaires (dont je parle aujourd'hui), mais également par exemple pour la conception d'une interface graphique : celle-ci doit être conçue pour répondre au besoin de l'utilisateur, et en cherchant à ce que la solution ergonomique soit simple et intuitive. Mais le développeur a tendance à se limiter dans sa créativité car immédiatement, il se demande "comment" il va faire pour implémenter cette solution innovante, et il aura tendance à aller vers des solutions ergonomiques dont il maîtrise mieux les aspects techniques, mais qui répondront moins bien à ce qu'il faut fournir à l'utilisateur.

Les étapes d'apprentissage du TDD

Un développeur, qui découvre les tests unitaires et le TDD, doit passer du "comment" au "quoi", et il lui faudra 3 différentes étapes progressives :

• Etape 1 : Il commence à implémenter la solution, le code de production, pour avoir une idée du "comment", et dès que possible, lorsqu'il a une vision rassurante de la solution technique, il peut imaginer comment tester et peut alors passer à la rédaction des tests unitaires
• Etape 2 : Plus besoin d'implémenter un début de solution, le développeur arrive à l'imaginer et l'anticiper, il peut là encore en déduire comment tester cette solution, il peut donc commencer directement par les tests, mais l'approche n'est pas encore correcte et efficace
• Etape 3 : A ce stade, le développeur ne se préoccupe plus du "comment", il se focalise sur le "quoi", sur ce qu'il doit obtenir et donc ce qu'il doit tester, peu importe la complexité de l'implémentation qui sera étudiée dans un deuxième temps

Remarques

• Une fois le "quoi" exprimé dans les tests unitaires, il n'est pas impossible que la solution technique à adopter soit vraiment trop complexe, il est toujours possible de réajuster les tests, mais au moins, on sera bien parti du besoin
• De même pour la testabilité du code : ne pas hésiter à adapter les tests (mais pas trop) pour éviter une usine à gaz dans l'implémentation
• Bien sûr, ces 3 étapes ne sont pas obligatoires (surtout la première), mais elles sont issues de mes observations et cette approche progressive est souvent non reconnue, y compris du développeur lui-même (qui pense partir du besoin mais pense trop tôt à la solution technique)

Conseils

Aux développeurs :

• Partez bien du besoin, penser au "quoi" : que dois-je obtenir ? que dois-je tester ?
• Oubliez la technique, ne vous posez pas la question du "comment" tant que le ou les tests ne sont pas entièrement écrits
• Ne doutez pas de vos capacités et compétences, lâchez vous, cette approche vous poussera à innover et progresser

Aux coachs, ScrumMasters et autres leaders :

• Ne soyez pas impatient, donnez du temps aux développeurs pour expérimenter et prendre conscience de l'approche proposée
• Assurez-vous que vos équipes travaillent sur des histoires (réellement) fonctionnelles, simples, claires et illustrées d’exemple (ce sera plus facile)
• Libérez du temps pour que vos développeurs s’entraînent (coding-dojo par exemple) : en sport, on n'essaie pas de nouvelles choses en compétitions !
• Incitez vos équipes au pair-programming, et proposez-leur des variantes : les tests écrits par un développeur et implémenté par un autre

Conclusion

L'apprentissage des tests unitaires est difficile, le TDD va aider, mais il faut du temps aux développeurs, ainsi que de la motivation et de la compréhension (pourquoi on fait tout cela ?).

J'en profite pour remercier une équipe en particulier, avec laquelle j'ai beaucoup travaillé autour des tests unitaires et du TDD, je pense qu'ils se reconnaîtront, je les félicite pour leur parcour, et je les remercie chaleureusement pour tout ce qu'il m'ont apporté !