Apprenez TDD

De tout l'arsenal du "craft", le Test Driven Development (TDD donc) est l'une des pratiques les plus difficiles à appréhender, possiblement la moins comprise, et pourtant la plus intéressante à utiliser.

Je ne connais pas de développeur pour qui passer au TDD ait été naturel. Pour beaucoup de professionnels, dont je suis, qui ont passé un peu de temps dans l'industrie, apprendre à utiliser TDD est difficile. Il faut désapprendre avant d’apprendre, se débarrasser de réflexes et d’habitudes de travail bien implantées. Comme souvent, durant un tel processus d’apprentissage, on passe par une phase très désagréable durant laquelle on a l’impression de ne plus savoir rien faire.

C'est une pratique mal comprise, parce que ce n'est pas une pratique de test, mais une pratique de conception. La fonction première du TDD est de nous permettre de faire de la conception logicielle itérative, informée, en s'appuyant sur une boucle de feedback très courte. Une fois qu'on l'a assimilée, elle nous donne un superpouvoir : c'est une méthodologie tout terrain, parfaite notamment quand on ne sait pas par où commencer. J'ai notamment vécu l'expérience de réussir un test technique, que je ne savais par quel bout prendre, grâce à cette technique.

Paradoxalement, même si ce n'est pas une pratique de tests, vous pouvez facilement vous appuyer dessus, mettre un peu de test-first ou test-after dans votre méthodologie, et obtenir à peu d'efforts un bon niveau de couverture de tests.

C'est peut-être la plus intéressante, parce qu'elle ne nécessite pas d'obtenir un accord de l'équipe, de la direction, ou de qui que ce soit pour être pratiquée. Bien sûr, c'est mieux si on peut évoluer dans un environnement de travail homogène. C'est d'abord une discipline individuelle, que vous pouvez toujours pratiquer.

Si j'ai un seul conseil à donner à un développeur pour progresser, c'est d'apprendre TDD.