Test-Driven Writing : TDD appliqué à l’écriture
Que pourrait donner l’application des principes de Test-Driven Development (TDD) à la réécriture d’une page de Wikipédia ? Et quitte à le faire, et si cette page était précisément celle de TDD ! Je m’étais donné comme objectif en 2018 de réécrire entièrement la page de TDD sur Wikipédia, à l’état d’ébauche. C’est maintenant chose faite, après une première étape en 2015 où j’avais déjà remplacé le schéma du cycle de développement de TDD.
Ma démarche de réécriture a été semblable au cycle micro-itératif de TDD. Je cible un paragraphe, puis une idée tirée de ce paragraphe. Quelle est précisément l’idée élémentaire identifiée ? Quels mots utiliser pour l’exprimer avec concision ? En quoi puis-je l’exprimer avec plus de clarté, une tournure fluide, avec pédagogie ? Quels sont les concepts associés, même implicitement ? Lesquels peuvent manquer ? Ce seront là mes critères minimaux : tant qu’ils ne sont pas satisfaits, l’idée ciblée est insuffisamment développée pour passer le test. Je commence par un paragraphe vide au-dessus de celui visé. Puis j’écris un premier jet qui apporte le minimum de sens acceptable en mettant bout à bout les concepts-clés. Ce premier jet fait même émerger un fil directeur, mais à ce stade, il est à peine perceptible. Pour qu’il le devienne vraiment, je dois procéder à des remaniements successifs. Quel est ce fil directeur manquant pour relier les concepts afférents à l’idée de départ de façon évidente ? Éventuellement, le début d’une deuxième idée relative à TDD a-t-il émergé du développement de la première ? Le cas échéant, il faut l’en extraire pour les séparer : tant que les deux idées sont fusionnées dans le même paragraphe, elles se chevauchent, s’entremêlent, et restent inaudibles, comme si une classe occupait plusieurs responsabilités.
Ensuite j’itère de paragraphe en paragraphe, voire de phrase en phrase — tout dépend de la densité des paragraphes — , de façon à ne négliger aucune des idées existantes, qu’elles soient exprimées ou sous-tendues. Je m’astreins à ne développer qu’une idée par paragraphe, en suivant l’ordre logique des étapes dans le processus de développement de TDD. Chaque cycle d’écriture est donc susceptible de me faire avancer d’une étape dans le processus de TDD, afin d’en restituer les rouages, en couvrant progressivement le schéma de synthèse. Ces étapes successives font parfois fortuitement émerger de nouvelles idées à développer. Par exemple, j’en suis arrivé à expliquer de quelles manières TDD permet à tout un chacun de gagner en productivité, un point très délicat à défendre et à argumenter, alors que d’aucuns invoquent encore des a priori de coûts liés aux tests.
Enfin, pour chaque nouveau paragraphe écrit, je relis l’existant pour m’assurer que je n’omets rien. Alors seulement je m’autorise à supprimer une ou plusieurs phrases. Autrement dit, je confronte les deux versions alternatives, j’en fais l’examen, et si ce dernier est concluant, je substitue la nouvelle version à l’ancienne. Cela devrait vous rappeler le Golden Master, qui donne tout son intérêt au kata Gilded Rose, ainsi que les tests dos-à-dos.
Du résultat j’espère que vous tirerez une meilleure lecture et compréhension de cette méthode de conception logicielle à la fois si particulière et si puissante, et néanmoins mal comprise, voire décriée faute de maîtrise. L’idée de transposer TDD à autre chose que le développement logiciel n’est pas inédite, cela s’appelle même le Test-Driven Work.
En réécrivant la page de TDD par petits pas, je souhaitais faire un don personnel en empruntant le chemin du compagnonnage. J’ai aussi pensé aux candidats, développeurs ou testeurs, en entretien de recrutement, qui peuvent être en difficulté lorsqu’il leur est demandé d’expliquer TDD. Entre le schéma qui représente le cycle de développement de TDD et les explications textuelles, vous avez dorénavant toutes les clés en main pour triompher de cette épreuve ! Restera quand même à relever l’exercice de codage en TDD si l’on vous en propose un en entretien, auquel cas rien ne vaut la pratique.
Les contenus de Wikipédia doivent être sous une licence permettant n’importe quelle utilisation, même commerciale, et modification. Aussi mes schémas relatifs à TDD et sous une licence moins permissive sont disponibles sur gearsoftesting.org, et plus précisément sur la page du tempo des tests.
