Envie d'un accompagnement personnalisé ? Rejoignez mon programme de mentorat pour bénéficier de mes conseils d'expert et d'un accompagnement professionnel sur-mesure ! Rendez-vous sur devclub.fr/mentorat pour plus de détails et réserver votre séance dès maintenant !
Super vidéo, très intéressante!! Ce serait cool si tu pouvais parler de comment structurer ton projet en termes de dossier, etc... En tout cas, un plaisir de suivre ton aventure :)
Environ 82 tests écrits XD tu m’as tué avec le environ et la précision derrière. En tout cas je n’ai jamais vu comment écrire un test (je suis très loin de ce niveau), mais j’aime bien comment tu arrives à « vulgariser » la chose. 😉 beau travail
Merci Seb, quand je serai suffisamment confiant moi même sur les tests, je vous ferai surement un tuto 😅 là, l'objectif est de partager ce point de départ qui est bon il me semble !
À LIRE : si vous voulez poser des questions pour la FAQ et apparaître dedans commencez votre message par #FAQ 👍 Également, cette vidéo n'est pas un tuto sur comment faire des tests, c'est juste mon témoignage de comment je me suis posé des règles cette semaine pour tester mon squelette de dashboard 😉 j'apprends chaque jour de ce domaine, alors je ne pense pas que ça soit a prendre au comptant et d'ailleurs n'hésitez pas à vous même donner votre méthode si vous en avez une 👍 ! De plus concernant le TDD, n'entendez pas quand je dis que j'ai du mal avec que c'est "du mal" dans le sens je trouve ça nul. Non, pas du tout, c'est dans le sens, j'ai pas encore le niveau d'après moi déjà pour écrire des tests de bases, je suis en train de créer une architecture pour de futures projets, c'est donc quelque chose qui se modifie constamment pour s'optimiser et de ce fait, le TDD dans mon cas est un frein, une contrainte que je n'ai pas adoptée pour l'instant. Si j'avais un niveau suffisant en test (ce que j'espère bientôt avoir) et que je ne perds pas 50% de temps mais qu'au contraire j'en gagne, bien entendu, j'opterai surement pour le TDD. Ce n'est juste pas pour l'instant possible dans le projet de dashboard que je réalise de travailler selon cette stratégie 😉 ! Quand on rédige une vidéo, on sait ce qu'on veut dire, mais c'est pas forcément comme ça que c'est compris ensuite, d'où ma petite précision 😉 merci pour vos commentaires 👍
Perso je teste toutes les fonctionnalités et je crée pour ça une page test/debug qui va recenser toutes mes fonctionnalités et je les mets en vert/ok si ça fonctionne. Puis je fais un test global si les fonctionnalités sont interdépendantes et je les mets aussi en vert/ok. Comme ça je sais au premier coup d œil quelle fonctionnalité pose problème. C est plus long mais comme ça je suis confiant du retour client
Très intéressant. Tu pourrais faire un tuto sur jest pour les framework JavaScript. Car c’est effectivement une part très importante du travail de développeur qui est trop peu abordé.
Hello, Je suis partagé sur cette vidéo, d'un côté tu mets le doigt sur pourquoi c'est important de tester, d'un autre pas sur ce qu'il faut tester et surtout comment tester. Faire des tests pour vérifier qu'un bouton est la, ça ne sert strictement à rien en Tdd, même en test unitaire. C'est pas le but, ça tu peux le tester avec le combo cypress cypress-axe et axe-core pour permette de vérifier l'a11y. Le Tdd est la pour te donner un filet de sécurité, comme tu le disais, mais pour vérifier une intention. Pas une fonction, mais un comportement, une fonctionnalité. Tester une fonction ça aura tendance à figer le code. Tester une fonctionnalité|comportement ça permet de s'assurer que ça fonctionne toujours, mais sans figer le code. Et c'est ça la force du Tdd. Tu devrais te renseigner sur ce qu'est le Tdd et comment on l'utilise en front, ça te ferai sûrement changer d'avis en t'ouvrant les yeux sur son réel intérêt et la façon dont on l'utilises.
Hello Yoann, merci pour cette critique constructive 👍 ! Je ne me place pas en tant qu'expert des tests, loin de là, j'apprends au fur et à mesure, c'est pour ça que je raconte cette semaine comment j'ai décidé d'implémenter des tests dans mon application. Si j'avais voulu faire une vidéo tuto, ça aurait pas été un Roadmap. Donc bien sûr ce n'est pas une méthode parfaite, c'est juste celle que j'ai adoptée cette semaine 😅. Mais il faut que tu te places au niveau de ce que je suis en train de faire : un squelette pour de futures applications. Ce n'est pas une application métier, ça se rapproche plus d'un kit UI évolué qu'autre chose. Donc ce que je dois tester, c'est si un jour j'exporte ce projet en tant que librairie, que tous mes composants UI répondent à leurs exigences. Et c'est forcément majoritairement une question de rendu dans ce cas. Quand je dis que je ne fais pas "trop" de test et que je vais pas vérifier si un sous composant fait ce qu'il a faire à l'intérieur d'un autre, c'est tout l'inverse de dire est-ce que mon bouton s'affiche bien. C'est plutôt "est-ce que mon formulaire possède un bouton qui va permettre de submit". Si demain quelqu'un utilise ma "librairie dashboard", il veut juste être sûr qu'en passant une action en tant que props à un composant formulaire, il va bien y avoir un bouton submit qui s'affiche et qui exécute cette action. Je test donc que ma condition "si une action est passée en props, affiche un bouton" et "si le bouton du formulaire est cliqué, l'action doit être appelée". Quand tu codes un squelette de base, tu peux difficilement tester autre chose que ça. Surtout quand tu rends les composants le plus stupide possible, et que tu en abstrait toute logique business. Bien entendu les test que j'écrirai lorsque je ferai des apps sur cette base de dashboard n'auront rien à voir. Mais comme je l'expliquais, je test brique par brique et lorsqu'on sait pas par quoi commencer ses tests, vérifier qu'ils répondent à leur substance est un bon point de départ : "est-ce qu'un bouton affiche bien le label qu'on lui passe en props ? ", "est-ce qu'il appel bien la méthode qu'on lui passe en props ?" Et je pense que ce type de test est loin d'être inutile. Par exemple, et c'est un élément d'UI que je considère comme important, mon bouton affiche une couleur en fonction d'une props que je lui passe. Mon implémentation repose sur une fonction externe au composant qui s'appelle getColor en gros (ça transforme un terme genre success en classe background green en gros). Si demain je modifie ou supprime cette fonction de mon squelette, je vais le voir direct dans mes tests avec tous mes composants qui l'utilisent et qui vont passer au rouge. Je saurai grâce au test que le problème se situe au niveau de cette fonction. Concernant le TDD, c'est possible que je n'en ai pas l'utilité dans mon projet tout simplement. Je comprends que cette stratégie soit utilisées pour des grands projets, dont le cahier des charges a été méticuleusement décrit, mais là je suis entre une phase de prototype et de réalisation finale, c'est impossible pour moi de faire du TDD, sachant que comme je le disais je ne sais même pas encore comment je vais implémenter tel ou tel chose. C'est pour éviter ce que tu décris, d'avoir des tests trop figés et de me ralentir dans le développement que je ne fais pas dans ce projet de TDD. Et les tests préexistent à la stratégie du TDD, qui n'est, comme je le précise, qu'une stratégie, pas forcément adaptée à tous les projets. Notamment le mien, celui de fabriquer la base d'un dashboard où je me rends compte au fur et à mesure de ce dont j'ai besoin, je n'ai aucune vision figée au départ 😅 ! Voilà une bien longue réponse, mais autant que j'explique mon point de vue si c'était pas clair dans la vidéo 😉
Petit complément également, c'est également intéressant de voir comment une librairie comme vuetify envisage les tests composants : github.com/vuetifyjs/vuetify/blob/248add9949a9b16cbea55163713983c8726e62ce/packages/vuetify/src/components/VBtn/__tests__/VBtn.spec.ts Tu verras que le type de tests est semblable à ce que j'avance 👍 (la différence c'est par exemple que ça ne va pas tester si un label est présent, puisque ça passe par le système de slot et pas en props, mais le reste est semblable)
pour ceux qui ont un doute, le tdd est tres puissant dans le cadre de la refactorisation car tu sais directement si les changements apportés sont réellement efficient et que tu n as pas fait tout pete
Top video, bien vulgarisée et qui pointe les questions essentielles quand on se lance dans une démarche de tests. Néanmoins, tu a une vision un peu biaisée du TDD. Le TDD est trop souvent vu comme une méthode visant à produire des tests. Alors que dans la réalité, c'est une méthode de réflexion pour produire le code final. L'écriture du test avant le code sert à structurer sa pensé plus efficacement que lorsque l'on se projette tout de suite sur le code final. Puis une fois codé avec les tests qui passent, on peu se faire plaisir à refactorer notre code comme on veut avec la sécurité que si les tests continuent de passer alors notre code est tjrs valide. Avec le TDD, on fini finalement par gagner plus de temps dans la production du code final que de temps perdu à rédiger les tests. Par contre, on est d'accord qu'il faut s'entrainer, l'efficacité commence à venir qu'au bout d'une semaine ou deux. ET il ne faut pas l'appliquer sur tout non plus, la pertinence du TDD sur de la mise en page est très discutable, mais prend tout son sens dans les services ou les fonctions utilisateurs. Voici une video qui fait un bon résumé du sujet "QU'EST CE QUE LA METHODOLOGIE TEST DRIVEN DEVELOPEMENT ? (exemple en JavaScript)" Et pour se convaincre du temps que cela fait gagner, essayer de faire le "kata mars rover" sans TDD et dites nous combien de temps cela vous a pris 😆 Pour le reste de la vidéo, je suis entièrement d'accord avec toi 👍
Merci pour ton commentaire 😎 ! Oui clairement j'en suis pas encore au point où j'arrive à faire ce "mental shift" sur le TDD, mais j'espère que ça viendra, justement quand les projets seront suffisamment complexes pour que ça devienne un vrai outil de réflexion et non pas une contrainte 👍
Merci pour ta réponse, je suis dev web Junior en freelance Ta réponse est intéressante (bien que je ne sache quoi penser de Mike Codeur.... : /), j'irai me renseigner un peu plus sur le TDD (que je n'ai jamais encore appliqué sur du dev backend (oui je sais, aïe aïe !)
@@skymer7471 On est d'accord au sujet de Mike, même si ça vidéo résume très bien le sujet 😉 Une autre commentaire cite Michaël Azerhad et sa chaîne WealCome, qui a 2/3 vidéos de mise en pratique très bien vulgarisées. J'aime beaucoup également la vidéo de Sandro Mancuso sur le kata Mars Rover. Et il y a l'excellentissime chaîne de Job Mit, qui ne parle que de TDD, Refactoring et Legacy code. Mais le plus important pour progresser en TDD, c'est de s'entraîner en privilégiant les katas plutôt que d'essayer directement sur du code de prod.
Merci David, d’ailleurs tu as fait une vidéo sur le sujet pour Flutter 😄 ? (Cette année je vais m’y remettre d’ailleurs, si tu veux un de ces 4 faire un feat, ça serait cool 😎)
Salut ! Déjà j'adore ce que tu fais, je trouve ça vraiment trop cool !!! Je pense que tu n'as pas été suffisamment sensibilisé au TDD et à sa réelle puissance, je te conseille de suivre (voire faire une formation avec, en tout cas c'est qui m'a débloqué personnellement) Michaël Azerhad. Pour moi la réelle puissance du TDD intervient quand tu écris tes tests pas à pas ("baby step") en décomposant ta feature tel que "le business/le produit" l'a demandé. Donc le premier avantage est de poser la feature que tu as besoin de faire, et analyser ainsi tous les edges cases / besoins par rapport à cette feature. Le 2ème avantage est comme tu l'as dis, arriver à un code le plus simple possible et écrit avec le moins d'effort possible étant donné que le TDD est là pour te guider dans l'écriture de ce test :) Les autres avantages sont évidemment de pouvoir avoir une app qui ne régressent pas dans le temps, étant donné que les tests déjà écris dans le passé deviennent des tests de non-régresssion dans le futur, sans compter le gain de temps apporté au temps de dev total. Quand tu dis que les tests rajoutent environ 50% de temps pour une feature donnée je ne suis pas d'accord ci ces tests sont écris dans le contexte du TDD :p Je ne sais pas si tu as lu le bouquin Clean archi de Robert C. Martin, mais il explique dans son livre brièvement que pour un même algo, entre une personne utilisant le TDD et une personne ne l'utilisant pas, il était en moyenne 25% plus rapide de faire du TDD que d'écrire son code puis les tests. Tout simplement car la personne qui a écrit son algo en TDD a justement été guidé par ses tests, plutôt que d'y aller comme une brut et faire des erreurs d'étourderie dans le code (ce que tout le monde fait!) :) J'ai moi même pu expérimenté ce ressenti lorsque j'ai fais ma formation avec Michaël Azerhad sur le TDD, ainsi que récemment lors d'un exercice d'équipe où le but était d'utiliser ensemble le TDD à travers un kata (numeral => roman numbers). En fait, le TDD te fourni un code très simple, que tu vas pouvoir refactorer rapidement. Les tests after te fournissent le code déjà refactoré, il est donc plus complexe d'écrire ce code depuis une feuille blanche, car on prend en compte trop de complexité à la fois, le TDD t'aide à te focaliser sur 1 chose à la fois :) Je tiens cependant à dire que je suis d'accord avec toi concernant les tests frontend pur, tester ses composants est pour moi pas utile du tout. Le TDD côté front intervient plutôt quand tu vas avoir de la logique composant, càd si une telle condition est vraie, tel bouton va se disabled, telles choses vont apparaitre... Sinon côté services comme tu l'as dis :) Bref j'espère avoir été clair en tout cas :p Continue comme ça t'es au top !!!
Hello Guillaume merci 🙌 ! C'est certain que je n'y ai pas été suffisamment sensibilisé, d'où le fait que j'ai du mal avec. J'ai du mal avec le TDD pas parce que j'aime pas. Certes c'est moins 'fun' mais, c'est surtout que ça n'est pas quelque chose que j'ai eu l'habitude de faire quand j'étais salarié... Si tu veux je passe de : "on peut faire les tests cette fois-ci ? (à ma hiérarchie)", en réponse : "je sais pas...tu penses que la feat sera finie d'ici la fin de la semaine ?". A devoir me forcer à faire les tests, pour ma propre montée en compétence. Donc j'essaie de trouver un premier point de départ 😁 ! Le bouquin de Martin est sur ma liste c'est clair, il faut absolument que je me décide à le lire 😎 ! Comme je fais à moitié du prototype et que j'ai zéro cahier des charges (faudrait que je m'en écrive un), j'avance à tâtons sur ce squelette de dashboard et c'est compliqué de dire : "ok le bouton la doit avoir un loading, c'est dans les specs, j'écris le test, puis le code". Mais clairement, je devrais faire comme ça, et je pense faire comme ça quand je vais passer en mode logique métier. Merci beaucoup pour ton commentaire constructif 😁 la route est longue, ça fait plaisir d'être bien accompagné 🙏
Je pense que tu peux aller plus vite dans tes tests en faisant que de teste d'intergration avec Testing Library+mirage.js. Toute tes fonction serais tester a travers tes composant. Avec mon équipe on a commencer les tests y'a 6mois sur react aujourd'hui on 140 composant tester 450 test et un coverage de 99% on a une fonction vide pas tester a cause de la librairy de style obligatoire.(on a pas fait 6 mois de teste on a fait notre premier projet avec une stratégie de test en front) Franchement passer la compréhension des jest.mock() c'est très facile de tester avec cette methode
Ça a l'air super cool, je viens de survoler ! Je pense que pour les suites de mon dashboard (mais pourquoi pas réécrire les tests de base avec cette librairie aussi), notamment quand je ferai les tests pour l'implémentation métier, ça pourrait être super utile ! Et du coup vous faites du TDD ?
@@devclub_fr je sais pas si ma réponse est passer ou pas donc je vais la refaire sans liens. Donc non le TDD on ne l'impose pas a la place on c'est mit d'accord sur des règles ADR ( voir model de github ) et on utlise husky(hooks git) pour forcer le run des tests et le linter(on ajoute des règles au linter et a sonarqube). On a choisis un composant = un teste dans nos Adr et le converage doit etre vert dans jest. Comme c'est des règles choisi et pas imposé bas elles sont suivie mais aussi modifiable si on les trouves trop contraignante. La serie des outils en "DD" comme c'est imposer et pas choisis ça tiens pas très longtemps en règle générale et c'est pas transmissible car trop stricte.
"Rendre les composants stupides", ce procédé me rappelle exactement comme une démarche avec Angular, le fait d'utiliser les services c'est un plus, React donne trop la possibilité d'écrire n'importe quoi un button n'est pas fait pour être "trop intelligent"
Oui c'est sûr que la rigueur d'un Angular a ce niveau là est top. Mais si tu adoptes Typescript pour React, t'inquiètes pas qu'il va te hurler dessus dès que tu fais un pas de côté 😄
@@devclub_fr Ça c'est vrai, surtout qu'avec TypeScript tu as le typage static mais bon sur le web je vois tellement de mauvaise pratique, des gens qui désactive le mode de vérification strict de TypeScript donc ...
C'est bien un domaine où je galère les tests unitaires j'ai vraiment beaucoup de mal à comprendre .. les ressources ( vidéo) la dessus sont pas folle en plus ! J'ai un projet ou je dois débug une app avec des test unitaires je te raconte pas le plaisir 😅
J'ai déjà vu ça dans des boites, de mon opinion c'est le meilleur moyen pour perdre du temps et établir une mauvaise communication entre les devs et les testeurs
