TDD n’est pas ce que tu crois.
Dans Test-Driven Development, il y a le mot “test”.
Tu te dis alors automatiquement que c’est une technique qui va permettre de vérifier que ton code marche.
TDD n’a pas pour vocation de vérifier que ton code marche.
Si c’était cela, TDD n’aurait en rien transcendé les esprits des développeurs, car l’aspect testing existe depuis des décennies.
Le but de TDD c’est tout l’inverse, c’est découvrir par magie le code à écrire qui solutionnera ton énoncé du premier coup !
TDD veut que t’arrêtes de réfléchir par toi-même dans ton coin.
Il a compris que 99% du temps tu t’aventures dans un nouveau bloc de code from scratch compliqué mêlant des boucles, des listes, des variables partagées, des duplications etc.
Il a compris que tu perdais un temps fou à coder une portion, très souvent hors-sujet.
Le problème c’est que tu remarques que t’es hors-sujet au bout de plusieurs minutes voire de plusieurs heures; voire…des jours argh !
Et hop, après 3 heures, un joli ctrl+A => suppr, petit café, quelques larmes versées et tu recommences ?
TDD désire désormais que tu réflechisses en compagnie de l’ordinateur, ton nouveau copilote afin de te notifier de tes hors-sujets/code mort/erreurs en 10 secondes max !
Il ne te laissera plus faire la moindre bêtise !
Comment fait-il, il manipule mon cerveau, me rajoute 50 points de QI, il me drogue le salopiaud ?!
TDD t’apporte une rigueur la plus extrême qui soit dans tes raisonnements algorithmiques.
TDD en un mot c’est une discipline de fer.
- T’as plus le droit d’écrire du code sans que l’ordinateur te l’ait demandé !
“Hein????? Il peut me parler ce stupide ordi ?” - Tu écriras le minimum de code que l’ordinateur t’autorisera à écrire et surtout pas plus !
“Bah voyons ! J’ai pas payé mon MacBook Pro pour qu’il me donne des ordres !” - Tu arrangeras À FOND chaque millimètre de code que tu écriras quand l’ordinateur te le permettra, et pas avant ! Tout code mort, défensif en mode parano, à la poubelle !
À partir de maintenant tu vas devenir un passionné de la propreté car TDD te met en valeur tous les outils de nettoyage dont t’as besoin ‘for free’ ! - Tu connais bien les tableaux les listes et compagnie ?
“Oui les ArrayList, les LinkedList, les HashSet, HashMap, je dois tous te les citer Mister”?
Et bien dorénavant tu en écriras uniquement quand l’ordinateur te l’ordonnera car tu auras désormais une liste des actions possibles à chaque instant ! (https://en.wikipedia.org/wiki/Transformation_Priority_Premise)
“WTF, c’est une dictature ton délire, genre il va me dire ce que je peux utiliser et ce que je peux pas ?!” - Tu arrangeras le code de tes tests autant que ton code de prod, si ce n’est plus.
“ Bah voyons, c’est du code qui va pas en prod, je vais pas me faire chier !”
Fais ce que je te dis ! Ca fait parti de la discipline sinon pas de magie à la clé ! - Tu vas apprendre à splitter un problème dans ton cerveau en petits problèmes à difficulté croissante.
Tu devras solutionner chaque petit problème un à un et surtout pas en même temps, en suivant toutes les règles précédentes scrupuleusement.
Rappelle-toi, l’ordinateur doit savoir toutes les 10 secondes où tu en es avec une belle barre verte de sorte à t’éviter de graves ennuis !
C’est lui ton guide ! D’où le terme “Driven” !
“Hey les mecs ! Il veut nous vendre TDD avec toutes ces règles farfelues et nous promet qu’on livrera plus vite les solutions marchant à 100% ?
Ca m’a tout l’air d’un faux prophète, on le pend les gars ?”
Les choses les plus belles sont souvent les moins visibles au premier coup d’oeil.
J’avais 8 ans quand j’ai vu ce super film de l’époque :
Et je me souviens d’une scène qui m’a bien fait comprendre que certaines choses qui nous paraissent insensées, qui semblent nous ralentir, qui semblent nous faire dévier de notre but, sont en réalité le tremplin direct vers la sublimation de soi.
Ce petit jeunot dans le film souhaitait apprendre le Karaté, il était venu chercher le Maître Yoda chinois pour qu’il apprenne à mettre des coups de pied circulaires tranchants et ainsi faire le beau devant sa copine.
Il était “chaud” quoi.
Puis le Maître Yoda chinois lui demande de nettoyer ses carreaux, sa voiture avec de jolis chiffons; et ce…à tous leurs rendez-vous, non-stop.
Le petit jeunot pète un cable et demande l’intérêt de faire tout ça !
“Je perds mon temps, j’ai pas mis un seul coup de pied dans tout ça !”
Le moment de clairvoyance par Yoda-Like en vidéo (à regarder !) :
C’est devenu un tueur en Karaté sans le savoir grâce aux corvées !
TDD c’est une corvée pour certains mais avec un dénouement aussi inespéré que fabuleux !
Toi t’es tout chaud, tu viens d’être embauché pour du React et du Scala et tu n’as qu’une envie c’est de créer THE app !
Alors tu souhaites esquiver toute discipline qui te ferait ralentir et faire fumer le clavier !
Sans discipline, tu seras ralenti voire carrément bloqué jeune inconscient; c’est inévitable.
TDD c’est d’une puissance inouïe mais pour s’en apercevoir, il faut accepter la discipline quelque soit les moments du projets; calmes comme hard.
Le rush est l’ennemi de TDD et il te demande de ne jamais rusher mais bien d’appliquer la discipline comme il se doit sans jamais prendre de raccourcis.
Et en bonus, en conséquence du respect à la lettre de cette discipline….TDD s’assurera que ton code marche à tout instant de la vie de ton projet ! Youhou, tu as enfin des tests de non-régression ‘for free’ ! Un code coverage à 100%, oui 100% !
Toutes ces suites de “tests”, arf allez j’aime pas le mot “test”, si t’as lu plus haut, ça s’apparente plutôt à des specs visant à te guider dans ton code n’est-ce pas ?
C’est juste que la spec est écrite avec un outil de testing (Junit/ScalaTest/PHPUnit etc.).
Alors oui, l’aspect “testing” est une conséquence heureuse de la pratique TDD.
Un bonus gratuit qui fera du bien à ton Manager. Que demander de plus ?
Conclusion
TDD ce n’est pas du test pour du test.
TDD c’est du design de code, une discipline qui si bien pratiquée te fera émerger inconsciemment des algorithmes si bien foutus qu’ils t’étonneront toi-même.
Si bien pratiqué, TDD ne te ralentira pas.
Au contraire, il te rendra XXX fois plus productif car tu arriveras à la solution sans aucun obstacle sur ton chemin, et tu pourras enfin dormir tranquille car ton code sera fiable et refactorable à souhait sans peur de tout casser !
Et crois-moi sur parole, je le pratique depuis 2011 sur des projets simples comme ultra complexes et pour rien au monde je ne retournerai en arrière.
Il m’a rendu bien meilleur développeur que je ne l’étais ;)
Si tu veux entrer dans la danse (et je te le conseille fortement), commence par regarder les épisodes 19 à 24 : https://cleancoders.com/videos/clean-code/advanced-tdd.
J’ai appris les bases de TDD grâce à eux en 2011 et c’est agréable à suivre !
Dans un prochain article, j’expliquerai ce qu’est un VRAI test unitaire et pourquoi beaucoup de gens interprètent mal cette notion.
Si tu penses que :
- Un test unitaire teste une seule classe, sans jamais traverser d’autres sur le chemin.
- Que les mocks sont une merveilleuse invention.
- Qu’un test unitaire est orienté pur développeur et ne teste pas de ‘métier’.
Alors tu es le candidat rêvé pour lire mon prochain post et constater que … tu te trompes totalement…
À toute ;)
