Le TDD est-il inutile ?

Le nouveau mouvement anti-TDD

Beaucoup de développeurs qui se sont mis à Typescript dernièrement se sont sentis pousser des ailes grâce à ses fonctionnalités de vérification en temps réel du matching des typages directement dans l'IDE. Il est vrai que cette approche de développement, par opposition au JavaScript, change énormément de choses et réduit déjà un grand nombre d'erreurs possibles avant même l'exécution. Je n'ai rien à redire là-dessus, je suis totalement convaincu qu'il y a un changement radical entre TS et JS avec une nette amélioration de la capacité à anticiper les bugs.

Cependant, ce mouvement va très loin, en allant même jusqu'à renier les méthodes TDD et les juger inutiles sur la base des vérifications TS uniquement. Ce mouvement a été renforcé par l'accélération des projets de type startup/POC. On veut faire du quick and dirty, on veut aller vite et sortir quelque chose, privilégier la rentabilité contre la fiabilité. Cependant, je pense qu'il y a un souci avec cette façon de penser. La fiabilité ne doit jamais être opposée à la rentabilité. Les meilleures applications et les applications qui durent dans le temps ont souvent réussi à allier les deux : rester fiables et rentables, grâce à un équilibre subtil entre les tests et la sortie de fonctionnalités.

L'idéal est de garder le maximum de performance en ne faisant pas trop de compromis sur la fiabilité. Entre nous, aux deux extrêmes, nous assistons à des points de vue aberrants, entre ceux qui veulent un coverage de 100 % et ceux qui ne veulent absolument pas faire de tests, je peux vous garantir que personne n'a raison dans ces extrêmes. J'ai vu trop de projets se planter lamentablement à cause de problématiques issues de ces points de vue :

• le 100 % coverage qui ne sort quasiment aucune feature,
• le no TDD qui est une passoire à bugs.

Et pour vous citer encore Clean Code, il y a trop de boîtes qui ont négligé les tests pendant très longtemps, jusqu'au jour où elles se sont mises à bugfix mais perdaient des dizaines de milliers d'utilisateurs par jour à cause des bugs. Dans ces moments-là, il est probablement déjà trop tard pour se dire : "Ah mais si on faisait du code fiable". Bravo, vous avez juste réussi à couler votre boîte !

Le problème des projets non testés

Je peux vous assurer qu'un projet sans aucun test, c'est l'enfer sur terre et j'en ai déjà fait les frais. 🥵

Lorsque vous travaillez en équipe, chaque commit est susceptible de casser un comportement et de créer un bug, car des développeurs poussent souvent leurs modifications sans tenir compte d'un comportement voulu ou attendu initialement, mais plutôt sur un besoin spontané.

L'absence de tests ne permet pas d'intercepter les régressions à ce moment.

De même, sur un projet de taille conséquente, l'absence de tests ne donne aucune ligne directrice sur ce qui est attendu comme cheminement vers une fonctionnalité. Les développeurs auront tendance à créer plein de libs et de fonctions sans savoir s'ils vont s'en servir réellement. Bonjour la perte de temps !

Le risque encouru est d'entretenir une dette tellement lourde qu'il faudrait des semaines voire des mois pour repasser dessus. De nombreux projets n'ont pas surmonté cette épreuve car c'est un moment stressant et sollicitant financièrement avec un risque quotidien de churn client (churn : le client arrête d'utiliser vos services).

En vous rappelant que tout cela aurait été évité avec de l'organisation et de la rigueur. Faire du TDD c'est aussi faire preuve de responsabilité, vis-à-vis de la boîte et vis-à-vis des clients.

Des sociétés telles que Knight Capital Group ont coulé à cause de bugs qui généraient des trades erronés sur une période de 45 minutes, entraînant une perte de 440 millions de dollars, un incident qui a coûté 75 % du capital de la compagnie. En 45 minutes !!! 🥵

Trouver l'équilibre dans la mise en place de TDD

Pour faire efficacement du TDD, il ne suffit pas de tout tester et d'avoir un coverage de 100 % et une inertie digne d'un paquebot.

Le fait de faire des tests, c'est aussi imposer un fonctionnement attendu pour un composant. Par exemple, un argument supplémentaire et obligatoire dans une fonction qui n'en attendait pas initialement, c'est potentiellement une régression à d'autres endroits du code.

Passer les tests avant de pouvoir push son code, c'est bien souvent : s'assurer que ce qu'on envoie ne casse pas un comportement voulu.

De même, le TDD aide au développement, lorsque l'on est en train de construire une fonctionnalité complexe qui s'appuie sur un enchaînement de fonctions pour le moment encore inexistantes. Il va donner une ligne directrice sur les fonctions que l'on aura à livrer et permettra d'anticiper le comportement attendu de chaque fonction, en matérialisant la spécification de ces fonctions.

Si l'on retire cette partie, notamment dans les projets de taille moyenne voire grande, il peut être difficile de savoir où va mener une implémentation car les équipes n'ont aucune direction, les TDD auraient pu jouer un rôle de balise dans ce brouillard.

En sachant que plus vous avancez dans votre projet, plus vous entrevoyez l'objectif de manière claire et précise, il se peut que vous ayez à repasser sur les tests pour leur donner une direction nouvelle, mais au moins, la direction existe, elle est posée et le cadre est donné.

Bilan après plusieurs années de TDD

Mes recommandations sont les suivantes :

• Mettre en place le TDD sur les fonctionnalités clés de votre application.
• Avoir une attention particulière sur les chemins les plus critiques : paiement, manipulation de données clients, manipulation de documents, exposition de données confidentielles...
• Ne pas aller trop loin en faisant du TDD sur les libs externes utilisées (ce sont aux libs de tester leur code et il est de votre responsabilité de faire un choix avisé lorsque vous sélectionnez vos dépendances), en revanche, tester la combinaison de plusieurs libs dans des TDD peut se faire si vous pensez que l'on arrive à un niveau de complexité nécessitant une vérification.

Depuis que je travaille en TDD, je dois admettre que je suis bien plus serein sur ce que je livre et je dors sur mes deux oreilles. Ce sentiment n'a pas de prix en tant que développeur, et je ne peux que vous recommander cette méthodologie. À moins de n'avoir absolument aucune conscience professionnelle, je ne sais pas comment font ceux qui disent s'en passer.