Bienvenue sur le podcast Artisan Developer, l'émission pour les programmeurs qui veulent vivre une carrière épanouissante.
Prêt à passer au niveau supérieur ? C'est parti !
Aujourd'hui je suis avec Xavier Knopp, Xavier bonjour.
Bonjour Benoît.
Pour ceux qui ne te connaîtraient pas ce que tu peux te présenter en quelques mois.
Xavier Knopp, je suis développeur, fan de développement, fan d'agilité, donc du développement depuis très longtemps, 25 ans ou plus, je sais plus, je ne sais pas compter.
Et actuellement, donc je suis vraiment un passionné du développement et je fais tout pour faire du développement au quotidien.
Et actuellement, j'ai rejoint une start-up depuis un an et demi comme co-fondateur, la start-up Vertis qui fait de la visite virtuelle.
J'ai rejoint en tant que CTO, en tant que développeur et je code tous les jours ce qui me fait énormément plaisir.
J'essaye aussi de promouvoir les bonnes pratiques pour les développeurs, notamment le TDD, auprès des équipes que je peux croiser rencontrés, également dans les conférences auxquelles je peux participer, ou co-organiser comme la conférence Alpecraft, dont on avait fait une première édition en 2019.
Et on discutait justement, tu me parlais de ta stack et t'es une stack avec du Django et du React en front.
J'ai souvent cette question de « Ok, mais comment tu fais pour appliquer du TDD sur des composants, sur du React, sur des machins ? »
Je suis toujours un peu court parce que ce n'est pas une technique que je connais et que je maîtrise.
J'essaye d'imaginer moi ce que je ferai, première démarche que j'aurai, c'est d'avoir une démarche un peu BDD vraiment très globale, et ça finalement, quelle que soit la composition, c'est un peu d'importance.
Par contre, j'imagine que dès que j'aurai voulu tester de manière un peu plus unitaire mes composants, je m'intéresserai à ça.
Et du coup, je suis vachement curieux, est-ce que toi, tu appliques du TDD sur ces couches là, on va dire, plus de vues, de front ?
Est-ce que tu as une approche globale ? Est-ce que tu ne t'en terres pas du tout dans tes tests ? Comment tu gères ta stratégie de test sur ta stack ?
Par contre, il y a une chose avant que moi maintenant qui est plus clair, c'est que le TDD est là pour m'aider.
Il faut que le TDD soit là pour m'aider. Donc, écrire des tests, je vais prendre un exemple, j'ai du calcul, j'ai de l'algorithme il y a à faire.
Comment je vais pouvoir vérifier le résultat, à part l'intégrer dans mon appli et voir les valeurs que ça me sort ?
Donc, à apprémenter un algorithme, là, le TDD va énormément m'aider dans le sens où je vais mettre des données en entrée,
j'attends un résultat numérique par exemple. Et donc, je sais, je peux facilement écrire un test,
appeler mon algo avec les 4-5 paramètres et la valeur que j'attends. Et là, le TDD va m'aider à être sûr d'avoir apprémenté le bon résultat.
Dans le cas du composant visuel, finalement, moi, j'ai une autre approche, le TDD, si tu veux, pour moi, il est visuel.
Je travaille beaucoup avec, j'aime bien travailler avec Storybook. Storybook, ça permet de lister, de visualiser ta liste de composants.
Et ça peut être dans un écran aussi. Mais Storybook, j'aime bien parce que ça force à faire des composants le plus pur possible,
avec juste des propriétés, mettre ton composant dans différentes situations et voir le rendu avec du hot reload.
Et finalement, moi, mon TDD, il est comme ça. Il est visuel. C'est-à-dire, le but, c'est d'être sûr d'obtenir le bon résultat.
Donc, dans le cas de mon algorithme, c'est du calcul qui va être fait avec des résultats numériques vérifiés dans le test.
Et dans le cas du composant visuel, ça va être mes yeux qui vont me faire ce feedback pour mettre au point mon composant.
Par contre, ça, ça sous-entend que dans mon composant, il n'y a pas de logique métier.
En tout cas, moi, c'est vers ça que je pense. Je parlais à l'instant de composants, ce que j'appelle pur, c'est-à-dire de faire des composants qui n'aient aucune logique métier, qui n'aient que des propriétés.
Aujourd'hui, j'ai une stack avec des composants React, du Redux, des requêtes faites ici et là.
Et même une requête pour aller chercher la donnée à afficher dans une page, par exemple, je ne vais pas la mettre dans le composant.
Je vais tout faire pour que le composant n'ait aucun effet de bord, un peu avec cette notion de pur ou un peu comme dans des architectures hexagonales ou autres.
Donc le composant, il n'est pas d'effet de bord.
Et du coup, dans Storybook, je vais pouvoir le présenter avec différentes combinaisons de ces propriétés et vérifier le résultat que j'ai.
Et une fois que j'ai ce composant pur, je vais pouvoir l'intégrer.
Et la logique métier, elle va être dans des composants beaucoup plus simples à tester.
Par exemple, si on fait du Redux, là, tu as du JavaScript qui est pur, c'est-à-dire que du JavaScript avec des actions des réduceurs.
Et notamment, les réduceurs, c'est assez facile à tester puisque tu as un état, tu balances une action et tu sais l'état que tu dois attendre.
Donc ça, tu peux le faire en tédé classique.
Ok. Donc ce que tu dis, c'est que tout ce qui va toucher à la couche graphique, tu ne vas pas forcément écrire de code de tests automatiques.
Tu vas prendre tes composants que tu vas mettre dans un espèce d'environnement qui va les décliner de différentes manières.
Et tu vas avoir un gros travail de séparation, des responsabilités où tu vas vraiment sortir tout ce qui est algorithmique de la partie des composants, tout ce qui est comportement.
Par contre, le seul truc qui me... Ça, je l'entends.
Le seul truc qui me gratte un peu l'oreille, c'est quand tu dis finalement, t'aider c'est mes yeux.
Ce qui me gêne là-dedans, c'est que pour moi, dans la notion t'aider, c'est que tu as abouti à quelque chose qui est automatisé en fait et qui est répétable de manière très rapide.
Parce que pour moi, le t'aider, c'est une question de boucle de feedback et de répétabilité de l'action.
Alors là, la boucle de feedback, tu la trévit parce que j'imagine que si tu ouvres ton panneau, d'un coup tu vois toutes tes composantes, ton oeil va vite détecter les endroits où ça ne va pas.
Ça, je veux bien entendre le côté rapide.
Par contre, le jour où tu as 1000 composants, tu n'as pas une procédure qui te donne une boucle de feedback super rapide sur toutes tes composants en fait.
Alors, ce que j'entends dans ce que tu viens de me dire, c'est le sujet de la régression.
C'est vrai que là, ce que j'ai évoqué avant, c'est le sujet de la mise au point.
Je t'en ai gardé un peu sous le coude pour la suite.
Donc la mise au point, moi je la fais comme ça.
Donc je vais essayer de développer mon composant pur que des propriétés.
Ce composant, il ne va pas faire de requêtes à Ajax ou de requêtes à un bacquette ou je ne sais quoi d'autre.
Et je le mets au point comme ça de façon visuelle.
Par contre, ce que j'ai mis en place, alors je t'avoue que ce n'est pas complètement à jour et j'ai dans ma liste de tâches à remettre ça d'appelon.
Ce que j'avais mis en place, c'était que ensuite, via Storybook, je connectais le rendu de mes composants sur mes tests unitaires.
Et donc lorsque je joue mes tests unitaires de toute ma stack, ça va jouer en quelque sorte le rendu de tous les composants,
tant des snapshots qui servent de référence.
Et donc ça, par contre, ça va couvrir la partie régression.
C'est-à-dire que ça va me garantir qu'au travers du rendu via Storybook et via des snapshots,
ça me garantit que le rendu du composant n'a pas changé par des modifs que j'ai pu faire ailleurs.
Est-ce que ça adresse le point ?
Ça répond complètement. En fait, là tu adresses complètement le côté automatisé.
La seule différence que tu dis, c'est que à ce moment-là, tu t'en sers vraiment dans une logique pure de non-reg,
mais finalement, tu vas quelque part ton test qui est automatisé, donc là ça me va.
Exactement. Parce que finalement, souvent, il y a un mélange des genres entre le TDD, le fait que ça produise des tests,
est-ce que ça m'aide avant, est-ce que ça m'aide pendant, mais ça va m'aider sur les...
En quoi le TDD va m'aider pour la non-régression ? En fait, c'est pas le TDD qui est pour la non-régression.
Le TDD pour moi, aide à avoir un code couvert, et c'est le fait que le code est couvert par des tests unitaires
qui va garantir la non-régression. Cet test, il pourrait être écrit après.
Ce n'est pas forcément la meilleure façon de faire, mais du moment que tu as un code testé, ça va te garantir la non-régression.
Ce n'est pas le TDD vraiment qui porte ça. Peut-être on joue sur les détails.
Mais du coup, l'analogie avec le composant, c'est ça. C'est que ce n'est pas exactement la même approche,
une mise au point visuel, et ensuite du test unitaire, comme je viens de l'évoquer via storybook et les snapshot,
pour garantir la non-régression sur le rendu.
Et il reste un dernier point, c'est le comportement.
Et là, par contre, ça, je vais le faire avec des tests unitaires plus classiques.
Alors soit en TDD, ou si je n'ai pas réussi à le faire en TDD, je vais écrire des tests après,
qui vont être de vérifier sur ce composant le plus pur possible.
Alors, j'ai dit que composant, il n'a en entré que des propriétés. Il ne va pas aller chercher des données par lui-même.
Par contre, ce composant, il va gérer des clics sur un bouton pour déclencher quelque chose.
Et donc, ce composant, je vais juste le donner des callbacks,
lorsque on clique sur tel ou tel bouton ou tel item, il va m'appeler des callbacks que je vais donner dans les propriétés.
Et ça, par contre, je peux le tester dans storybook, mais ce n'est pas automatisé.
Je peux le vérifier dans storybook que ça marche.
Et ça, par contre, je vais essayer de le couvrir par des tests unitaires,
où je vais faire une instance, je vais instantiellement composant.
Je vais aller chercher dedans le bouton, je vais simuler un clic, et je vais vérifier qu'on m'a bien appelé ma callback,
qui est souvent une fonction boquée avec geste.
Moi, j'aime bien ta notion de séparer ce truc en trois étapes,
qui est la mise au point, la non-régression et le test du comportement.
Je suis assez d'accord avec toi de dire que la non-reg est un side effect de TDD,
plutôt positif du reste, mais un side effect.
Et ce n'est pas forcément ce que je vais rechercher en premier lieu.
Ce que je vais rechercher avec TDD, c'est le feedback rapide sur mon code, en fait.
Est-ce que je suis en train de faire va dans le bon sens ? Est-ce que ça marche ?
Est-ce que je n'ai pas cassé des choses ? Globalement, je vais vite.
Pour moi, t'aider c'est une question de feedback.
C'est pour ça que je revenais sur cette notion de est-ce que tu l'automatises ?
Parce que si tu ne l'automatises pas, tu ne peux pas avoir un feedback rapide.
Donc après, ce que tu fais, me parait hyper intéressant,
c'est-à-dire le coup des steps, je pense que c'est pertinent.
Certains diraient que, certains purés diraient que c'est certainement pas du TDD,
mais on s'en fout.
En fait, l'essentiel, c'est est-ce que ça couvre à ton besoin ?
Est-ce que ça répond à ton besoin ?
Et est-ce que tu es efficace avec ça ?
Visiblement, tu as l'air de te sentir efficace avec ça ?
Oui, oui. Et c'est pas du TDD.
C'est pas du TDD.
Mais pour moi, sur du backend, où là on est à la veuve,
contrairement aux frontes où on a du visuel qui peut nous aider,
tu viens de dire, quand je code, je vais être sûr que je fais le bon code.
Et quand tu codes du backend, ou même dans le front, mais des parties algorithmiques,
tu es à la veuve.
Donc, c'est là où le TDD, notamment avec des tests unitaires basés sur des valeurs de résultats,
là le TDD prend tout son sens et a tout son apport.
Mais par contre, sur des choses qui sont visuelles,
pour moi, aujourd'hui, c'est un peu absurde de vouloir absolument appliquer du TDD.
C'est-à-dire, je vais écrire un test unitaire qui vérifie que j'ai bien une div avec telle classe
et dedans une autre div avec telle autre classe, etc.
Et ça, pour moi, c'est totalement contre-productif.
Ça, j'aime bien cette notion-là, d'être capable de dire le TDD d'eau à me servir.
Je ne dois pas devenir exclave de la procédure.
Et quand le process me semble non pertinent ou trop coûteux ou inefficace,
je fais autrement et c'est OK avec ça.
J'aime bien cette approche-là.
Plutôt que d'avoir une approche dogmatique, tu te dis que si tout doit être fait de cette manière-là,
j'entends ce que tu dis, ce n'est pas toujours pertinent.
Je vois la Timebox qui explose tout repos, que ce soit le mode la fin.
Xavier, si les auditeurs veulent en savoir plus, ils peuvent venir.
Pour l'instant, le mieux, c'est de me chercher sur un moteur de recherche.
On doit pouvoir me trouver sur Twitter, où je suis plus ou moins actif,
sur LinkedIn où je suis très peu actif.
Et on doit pouvoir trouver mon blog un peu ancien.
Mais je travaille sur...
Je suis en train de travailler pour sortir un blog un peu technique au sein de Vertis.
Ça prendra un peu de temps, mais ça va bien.
Merci Xavier d'être revenu.
Merci Benoît pour l'invitation.
Quand à toi, cher auditeur, j'espère que tu as apprécié ce podcast.
Si tu as envie d'aller plus loin, si tu as envie de te former, si tu as envie de creuser sur ces sujets-là,
je t'invite à rejoindre la Maison des compagnons.
On a tout un programme de compagnons, tout un cursus qui s'appelle le Cursus Artisan Developer
pour t'aider entre autres à apprendre à faire du TDD.
Je t'invite à venir sur maison.artisandeveloper.fr.
Je te remercie et je te dis à bientôt.
Sous-titres réalisés par la communauté d'Amara.org