Transcription

• Speaker #0

  Bonjour et bienvenue sur ce nouvel épisode du podcast PunkinDev. Si vous avez lu le titre, vous pensez certainement que je vais parler de TDD, cet acronyme pour Test Driven Development. Eh ben, raté. Enfin, si, je vais en parler, mais pas tout de suite. D'abord, une petite histoire. Il y a quelques années de ça, un truc un peu à la mode s'était mis à fleurir dans mon entourage. C'était la slackline. Vous voyez ce que c'est ? Un genre de gros élastique, un peu large, tendu entre deux arbres ou deux poteaux, avec des gens étranges qui s'amusent à essayer de tenir dessus, comme des funambules un petit peu, avec du rebond. Les meilleurs d'entre eux y font même des figures. Je me souviens très bien quand ça a commencé à marcher. On nous vendait ça comme LE truc. A la fois bon pour la tonicité musculaire, pour le cardio, mais aussi excellent contre le stress. Comme quoi ça te muscle tout en te détendant les nerfs. Magnifique ! Moi, bon mouton, je me suis dit Banco, ce truc est fait pour moi ! Ça marche le marketing, vous avez vu ? Alors j'ai squatté un spot de Slack avec des collègues. J'ai essayé une fois. Bon, je suis tombé. Alors j'ai essayé une deuxième fois. Je suis tombé encore. Puis au bout de 15 essais, tout ce que j'ai réussi à faire, c'était tomber moins vite. Alors qu'on me vendait un truc qui allait me muscler et me détendre. Alors que ça m'a énervé à fond. Si je fais le bilan là, tout de suite, après ces premiers essais, mal aux fesses, hyper énervé. Puis j'ai perdu des potes parce que je suis parti en insultant tout le monde, ça m'a gonflé. Bon allez, j'arrête ici mon histoire. À demi fictive en plus. On va la faire simple, vous avez compris où je voulais en venir. Pour moi, TDD, c'est la slackline. Note que j'aurais pu prendre n'importe quelle autre discipline, un peu technique, comme un sport ou un instrument de musique. J'ai employé le mot discipline. Eh oui, TDD est une discipline à part entière, une discipline qui mérite et qui nécessite qu'on s'y poche un peu plus de 30 minutes pour commencer à en saisir l'essence. Pourquoi je parle de ça comme ça ? Eh ben, tout simplement parce que j'ai l'impression que depuis quelques mois, années, je sais pas trop, TDD a commencé à devenir un vrai buzzword dans le monde du dev. Comme si le fait de mettre ces trois lettres TDD dans les équipes et les fiches de poste, ça allait révolutionner l'univers de la création logicielle. Bien souvent, et je le déplore, c'est surtout de la com. Tant le chemin est long avant que TDD ne devienne un standard dans notre industrie. Je me suis même heurté à cet écueil avec certaines équipes. Avec des phrases que vous avez probablement déjà entendues. TDD ! Ouais, on connaît, on nous a expliqué. Mais ça s'applique pas à... pas ici projet trop complexe ou encore oui tdd c'est marrant sur un kata mais dans les vraies vies ça marche pas ça peut pas s'appliquer exactement comme le gars qui espère bénéficier des effets positifs de la slackline après une intro de 30 minutes qui songerait à faire deux tutos sur un langage et prétendre que ce langage est bien rigolo mais pas adapté à la prod tdd et tout sauf une science exacte c'est un outil une méthodologie avec ses avantages inconvénients ses façons de la pratique et Et surtout, TDD à un coup. Oui, bien pratiqué, TDD fera gagner du temps et de l'argent en projet. C'est évident. À court, moyen et long terme. En revanche, combien de temps faut-il pour maîtriser vraiment TDD ? Là-dessus, j'ai aucune réponse fiable et définitive à apporter. Tout dépendra du contexte dans lequel vous allez évoluer et quel sera votre entourage. Quelles seront vos capacités d'apprentissage et d'adaptation. Il n'y a pas de vérité là-dessus. C'est différent pour tout le monde. Pour ma part, j'ai mis très longtemps, plus de 6 ans je pense. Et je pense être encore loin d'avoir exploré toutes les dimensions de TDD. On peut trouver ça long ? Ouais, vraiment, je trouve ça long. J'ai plus appris les deux dernières années que les quatre premières. La cause ? Le contexte. J'ai une première exposition à TDD dans le cadre d'un nouveau projet relativement simple. L'architecte en place avait choisi de s'appuyer sur moi et ce nouveau projet pour commencer à intégrer TDD dans la liste des pratiques de l'équipe. C'était une très bonne idée. Premier problème, mon niveau global en test automatisé, en test unitaire, était plutôt embryonnaire à cette époque. J'ai tout vu d'un coup. Inversion de dépendance, MOG, assertion, puis toutes les lippes qui vont avec, plus la méthodologie TDD. Mais globalement, tout s'est bien déroulé. Le projet est sorti avec un plutôt bon niveau de qualité. Mon architecte était encore là, assez régulièrement, pour suivre que je gardais le cap. Honnêtement, la méthode m'a énormément plu. J'avais la sensation de produire quelque chose de bien meilleur qu'avant. Le souci a été qu'après cette étape... la prestat de l'architecte a été stoppée par le client et trop cher sur le long terme et que seul avec ma méthode je n'avais ni l'expérience ni l'aplomb pour générer de l'adhésion à cette nouvelle façon de faire je n'avais pas suffisamment pratiqué pour être capable de la réutiliser sur un autre projet existant du même client la marge était trop élevée et dans le fond je pense que j'avais pas vraiment compris ce que je faisais pour y revenir avec plus d'efficacité Je me suis largement appuyé sur les codings dojo. J'ai empilé des katas, souvent en pair programming, avec des gens plus expérimentés que moi sur le sujet. Comme le sportif, qui enchaîne ses exercices avant son match ou sa compétition. Ici, le match, c'est le code de prod. Par chance, j'ai pu trouver une mission avec quelqu'un de déjà formé. Je n'avais donc pas à le convaincre, bien au contraire. J'ai pu commencer à appliquer tout ce que j'avais vu en kata, avec l'assurance que les sessions de pair et les codes review, elles me colleraient les bons reminders, que je n'allais pas partir dans n'importe quelle direction. Aujourd'hui, je pense avoir assez de recul pour prétendre faire du TDD de façon tout à fait décente. J'ai pris quelques écueils sur ma façon de rédiger, d'organiser, de concevoir mes tests. Et je pense avoir suffisamment aiguisé ma compréhension pour pouvoir accompagner des équipes qui souhaitent s'y mettre. En revanche, il est clair que l'univers de TDD est vaste et que j'ai encore beaucoup d'éléments à intégrer à ma pratique, à découvrir. Car oui, j'ai envie de parler d'un univers TDD, avec ses espaces connexes, ses notions propres. Au final, je n'ai même pas vraiment défini ce qu'est TDD, ni comment on le pratique, mais j'y reviendrai dans de futurs épisodes, c'est prévu. En revanche, ce que je trouve important ici, c'est de bien prendre conscience, avant de s'y mettre, que TDD n'est pas un outil basique, assimilable en quelques minutes. Il s'agit d'une discipline à part entière, qui réserve son lot de découvertes, parfois de frustrations, liées à une courbe de progression qui sera tout sauf linéaire. Mais comme toute discipline, le plaisir naîtra de la progression et de la sensation de maîtrise qu'on va pouvoir développer au fur et à mesure du temps et des progrès qu'on va faire. J'espère que ce premier épisode traitant de TDD vous aura plu. Si vous avez des interrogations ou des éléments que vous souhaiteriez voir abordés dans de futurs épisodes sur ce sujet ou un autre, n'hésitez pas à venir m'en parler sur Twitter, arrobase sylve underscore coude, ou LinkedIn sylvain couder. Il me reste à vous dire à bientôt. pour un prochain épisode. D'ici là, geekez bien, codez bien !