Provoquer volontairement le bruit
[TDD]
Dans mon post d’hier, je considére la pratique de TDD comme “création d’un sous-système de correction du bruit dans un système qui articule un flot de conception”. Ouf. Si vous n’avez pas l’histoire, je vous recommande de passer par le post d’hier.
On y lit que souvent, les gens qui trouvent TDD inutile (ils sont nombreux : une majorité) argumentent que des tests qui passent d’emblée constituent une perte de temps.
Objection (2) : Dans la pratique, en TDD, un test ne passe jamais d’emblée.
En effet TDD pousse la logique de régulation jusqu’à provoquer volontairement le bruit.
Qu’entend on par “provoquer volontairement le bruit ?”
Alors qu’elle conduit sur une route enneigée et verglacée, Allison exerce sur le volant, le frein et l’accélérateur, un contrôle parfait et une conduite sans à-coups : son but est d’atteindre la meilleure vitesse possible en évitant toute perte d’adhérence.
Problème : Comme elle roule très doucement le comportement de son véhicule, qui ne dérape pas, ne lui permet pas d’apprécier le degré réel d’adhérence de la route. Comment savoir si sa conduite n’est pas trop prudente et donc trop lente ?
Solution : Allison donne un très (très) léger coup de volant, histoire de mesurer le dérapage qui se produit et d’apprécier le niveau d’adhérence effective sans perdre le contrôle.
△
Alors qu’il participe à une course d’orientation, Thomas sait d’après sa carte, qu’une rivière barre sa route dans 400m, plein Ouest, et qu’un pont se trouve là-bas, en face.
Problème : Tout à fait en face ? Il n’est pas sûr. S’il ne voit pas le pont lorsqu’il arrivera à la rivière, il lui faudra chercher ce pont soit au Nord, soit au Sud, avec 50% de chance de perdre la course.
Solution : Thomas court direction Ouest et légèrement vers le Nord. Dès la rivière atteinte, il courra vers le Sud, certain de trouver le pont.
Dans ces deux situations, l’insertion délibérée d’un bruit permet d’éviter une incertitude sur le niveau de bruit plus grand.
△
Jérémie introduit, dans le code d’un système complexe, une nouvelle vérification automatisée, portant sur une subtilité dans une règle de calcul historique.
Problème : Quelque fois une vérification écrite de cette manière avant de coder le changement correspondant, passe au lieu d’échouer comme on s’y attendrait. C’est le doute : est-ce que le système inclut déjà le comportement ? Est-ce que la vérification est elle-même erronée ? Est-ce qu’elle passerait dans n’importe quel cas ? Où est l’erreur ? Qui se trompe ?
Solution : Après avoir écrit son test, et avant de lancer son exécution, Jérémie introduit dans le code de production un comportement très simple, incorrect, qui doit faire échouer son dernier test. C’est le step 1 du cycle TDD : écris un test en t’assurant que celui-ci échoue pour la bonne raison.
Comme dit un proverbe bruitiste : ne fais pas confiance à un test que tu n’as pas vu échouer.
Stay Tuned !