Bienvenue sur le podcast Artisan Developer,
l'émission qui combine technique et agilité pour partager la passion du code.
Aujourd'hui, je suis avec Xavier Nobbre et Xavier, bonjour.
Bonjour Benoît.
Aujourd'hui, je te propose qu'on aborde une question qui est sur
comment est-ce qu'on applique le TDD dans la vraie vie,
avec en particulier ce prisme qui est
une fois qu'on a fait des catas, une fois qu'on a pu partager sur ces notions,
moi je me retrouve des fois avec des gars qui me disent bon écoute Benoît,
est-ce que tu nous as appris c'est cool, mais nous le dernier exemple en date que
j'ai c'est nous tu sais on fait une application mobile qui est juste en front,
qui n'a aucune intelligence, toute l'intelligence, toute l'algorithmie qui est
déplacée sur le serveur, à quoi ça va nous servir le TDD.
Oui effectivement moi aussi j'ai ce genre de retour ou par exemple
quand je fais des petites présentations, petites présentations, théories et des
mots d'une heure sur le TDD, souvent les premières réactions c'est oui mais nous
on fait du front, oui mais comment tu fais avec la base de données, oui mais comment
tu fais quand on communique avec l'extérieur. Moi ma réponse à ça c'est ok là
vous me parlez de situations qui sont un peu particulières, un peu
avancées, par exemple j'ai eu le cas hier un gars qui me dit oui sur le
backend je vois bien mais le front tu fais comment et je lui ai répondu si sur le
backend tu vois bien commence déjà par en faire sur le backend. En fait c'est
étonnant je ne sais pas pourquoi les gens tout de suite ont l'air de se
bloquer en se procheant, en se posant les questions des cas qui vont poser
problème. Donc ça c'est une première chose donc moi je leur dis déjà faites
en là où ça vous semble moins impossible et ensuite pour moi
il y a déjà un autre point aussi c'est le retour sur l'instissement.
Moi je suis un fan du test unitaire du TDD mais moi même au quotidien je vais
pas forcément tout couvrir toutes les parties de mon application par du test
unitaire je vais le faire à bon escient et surtout mettre cet effort là sur
les parties où vraiment il y a un retour sur l'investissement donc ça ne se met pas forcément
de partout. Et pour revenir à ta question par exemple sur le front ce que j'explique
souvent c'est qu'il y a toujours un moment où on va arriver à la limite de ce qu'on
de ce qu'on sait tester c'est à dire que moi en tant de développeurs je vais arriver à un moment
sur du code que je ne fais pas savoir tester. Alors soit parce que ça ne peut pas se tester
en test unitaire vraiment même par les experts les plus les plus expérimentés ou en tout cas
c'est plus souvent le cas parce que moi avec mes compétences aujourd'hui je ne sais pas tester ça.
Et je donne par exemple exemple du code front ou alors du code qui interagit avec une base de données.
Je prends souvent par exemple cet exemple là de la base de données en fait il y a des solutions
pour faire du test unitaire avec une fausse base de données montée en mémoire d'ailleurs mais
lorsqu'on monte en compétence sur ces sujets là on ne va pas commencer par ça parce que c'est déjà
plus compliqué donc on ne va pas pouvoir tester ce code là donc déjà se contenter déjà de tester
le reste et de ce qu'on peut et ensuite pour moi il y a un principe que j'ai découvert à force de me
poser des questions il y a quelques années c'est finalement de repousser les limites de ce code que
je ne sais pas tester ou que je ne pourrais pas tester et pour revenir aux frontes ce que j'ai
réalisé à quelques années et c'est valable pour plein d'autres domaines de notre application c'est
que dans mon front je mélangeais la présentation et la logique métier et le jour où j'ai réalisé ça
et que j'ai essayé de séparer la logique métier de la partie présentation et ben j'ai pu tester
la partie logique métier donc j'ai pu tester plus de choses que ce que je testais jusque là et je
me suis retrouvé avec une couche de présentation que je ne savais pas tester et que je ne teste
aujourd'hui toujours pas mais où ça va être du code vraiment minimaliste donc pour moi une des
principales réponses si je devais en résumer deux c'est un concentrez-vous déjà sur ce qui vous
semble testable et deux le principe de repousser les limites en séparant le code qui vous semble
pas testable et d'extraire de ce code là ce qui pourrait être testable dans d'autres classes
oui c'est une approche intéressante moi j'aime bien le côté de écoute fais déjà ce que tu peux
parce qu'au moins ça le mérite d'amener à s'entraîner c'est vrai que chercher l'exhaustivité
tout de suite c'est peut-être c'est peut-être une marche encore trop difficile à faire moi j'ai une
autre approche quand on me challenge sur ça c'est d'ouvrir le code et de regarder et j'attaque
l'angle j'attaque ça sous l'angle de la complexité cyclomatique je vais attaquer ça par l'angle
et je vais rechercher très concrètement je vais scanner le code et rechercher tout ce qui est switch
if tout ce qui est branchement en fait parce que implicitement un branchement qu'est ce qui veut
dire il veut dire qu'à un moment donné il y a une décision qui est prise par le code d'aller à
droite ou à gauche et ça pour moi c'est vraiment le truc qui est par excellence testable quoi et
et force est de constater que dans une même dans une API même dans une nappe qui ne fait que
communiquer avec une API pour présenter de la donnée bah il y a forcément des branchements en
fait il y a toujours des branchements le mec il est logé il n'est pas logé le gars c'est un
utilisateur basique ou un utilisateur premium et en cherchant comme ça les if on trouve moi je
trouve des points d'accroche et ça donne des sujets de de sujets de travail et les gens se rendent
compte effectivement que ben ouais il y a matière à et ce que tu dis est intéressant c'est à dire
que deuxième point que tu es évoqué c'est à dire que en fait au travers des if qu'est ce qu'on
va chercher indirectement bah on va chercher la la la logique métier qui est qui est embarquée
dans la présentation dans la couche de présentation et donc ça c'est pour moi une bonne manière
d'entrer en matière et d'aller commencer quoi parce que toute la difficulté du démarrage c'est
de commencer quelque part oui alors est ce qui est rigolo d'ailleurs c'est que on est fan tout toi et moi
de convaincu par le tdd et là on parle l'impression de de rajouter du du test enfin tu parles de
code existant donc on est plutôt dans une démarche de test test after et en t'écoutant je me dis
que c'est peut-être peut-être aussi une piste intéressante en tout cas pour les développeurs c'est
à la fois d'essayer le tdd et à la fois d'essayer de rajouter aussi du test des fois sur du code
existant parce que la démarche du tdd on l'a déjà évoqué plusieurs fois dans les épisodes
passées c'est quelque chose de de pas évident donc des fois prendre du code et de mettre du
essayer de mettre du test dessus j'en viens pour être pour être très concret moi j'aime bien être
pragmatique pour donner des idées et des images sur le front par exemple je reçois une donnée de
mon back end qui contient une information alerte ou pas alerte et donc je vais développer un composant
et si il y a alerte mon composant se met en rouge avec du css background rouge et ça si je le teste
et j'ai fait l'expérience à plusieurs années avec du jasmine jasmin jquery et tous les plugins
qui allaient bien et en fait j'avais du css background rouge dans mon test unitaire et dans
mon code et quand je regardais mes deux codes mon test et mon code de production et ben ça
se ressemblait comme de goutte d'eau et je me suis dit bah là il y a problème et pour revenir à ce que
j'expliquais tout à l'heure pour moi la solution c'est qu'en fait on a mélangé la deux choses et
donc moi ce que j'ai fréquonisé c'est de séparer en deux de faire un composant qui est rouge ou qui
est vert mais il sait pas pourquoi il est rouge ou il est vert on a juste une méthode pour lui dire
toute main rouge toute main vert et lui ce composant quand on lui dit toute main rouge css background
rouge et ça je le testerai pas en tout cas pas en tdd et avec les moyens qu'on a aujourd'hui par
exemple je mettrai dessus du geste avec du snapshot pour vérifier la non-récrétion mais parce que
je l'aurais validé visuellement une fois ce composant et par contre la logique de je vais chercher
dans le backend des infos et si c'est danger alors il faut mettre en rouge ça ça avait un autre code
javascript qui finalement lui il va être pur javascript et va pouvoir être testé en simulant
une réponse du backend et en faisant un moque du composant et en vérifiant qu'on appelle la méthode
mettois en rouge ouais t'es un très bon exemple qui illustre cette idée de séparer le la dimension
métier de la couche vraiment dédiée à la présentation voilà et dans cet exemple là souvent je
m'appuie sur cet exemple assez simple pour montrer que on va repousser les limites de ce qu'on ne
sait pas tester et donc de séparer d'essayer de sortir de regarder dans le code est-ce qu'on
mélange pas de la logique métier avec d'autres choses avec le code d'interaction avec la base
de données ou avec le code de présentation dans le front et c'est souvent le cas et c'est souvent
ça qui fait que finalement par contamination on a tout un tas de code qu'on ne sait pas tester
parce que dedans il y a de la requête SQL ou il y a du code html css et que ça c'est ça c'est
très compliqué voir impossible à tester donc l'idée de séparer ça bah écoute j'ai dit je te
remercie je te propose je te propose que ce soit le mot de la fin et bah pas de soucis merci à
toi benoît si les auditeurs veulent en savoir plus ils peuvent venir regarder où sur ce que tu crie ce
que tu fais ce que tu produis et pas toujours pareil le mieux c'est mon blog qu'on trouve assez
facilement en tapant mon nom que ça vient d'opre sur un moteur de recherche mais blog et qui mal
heureusement n'est pas assez actif à mon goût mais bon peut-être un jour je te remercie Xavier
merci à toi quand à toi cher auditeurs je t'invite à rejoindre la communauté des développeurs
passionnés sur artisandeveloppeur.fr et je te dis à demain