Hello Mike ! Bonne démarche que de vouloir sensibiliser les nouveaux développeurs (ou même les pas nouveaux d'ailleurs) aux tests automatisés ! Par contre ce que tu décris dans cette vidéo c'est du Test First, pas du TDD. En TDD tu n'écris pas tout le test d'un coup, tu écris d'abord le cas le plus simple, tu le fais passer, tu passes ensuite au cas plus complexe, tu le fais passer, etc., jusqu'à résoudre le problème initial. L'avantage est que tu as un feedback très rapide et pertinent qui t'évite un maximum d'avoir à utiliser des console.log par exemple.
Effectivement ce n'est pas tout à fait du TDD. Mais dans certains cas (la plupart en fait), c'est possible de tout tester dès le départ, surtout si c'est spécifié dans le cahier des charges, donc pourquoi s'en priver ?
@@thierryleriche1196 si c'est spécifié dans le cahier des charges/user story (selon la méthodologie employé), rien n'empêche de passer par le double loop of TDD. En fait, ça s'y prête encore mieux que le Test First
@@andonary Le truc qui me gène le plus dans le TDD pur, c'est quand on a déjà toutes les cartes en main dès le départ mais qu'on ne code pas tous les cas proposés d'un coup. A partir du moment où un mec s'est cassé la tête a mettre des exemples dans les specs, on devrait les reprendre direct. Pourquoi se priver, se brider ?..
@@thierryleriche1196 C'est totalement compatible ! Tant mieux même, on peut utiliser les exemples du AMOA et les enregistrer comme test d'acception. Ils seront ton indicateur comme quoi tu aura finis ta tâche. Puis là vient la boucle du TDD pour trouver le meilleur algorithme fiable, évolutive et facile à maintenir. Imagine que l'application est un jeu de bowling. Il y a plein de règles de gestion très compliqué dans un jeu de bowling pour calculer le score. Le AMOA t'aura sorti 1 exemple de jeu qui indique comme score final 127. A partir de là, comment tu fais pour coder et arriver jusqu'à 127 dans le respects des règles de gestion? C'est compliqué. TDD consiste à simplifier le problème pour pouvoir découvrir ton algorithme au fur et à mesure.
"Tester c'est douter" : Douter du code qu'on va produire sois même est une bonne pratique ! Il ne faut pas voir cette maxime comme "Les tests ne servent à rien", mais "Le code que je vais produire je n'ai aucune certitude/preuve qu'il fonctionne, le test m'aide à lever les doutes". C'est super d'amener des supports d'apprentissage accessible sur ce genre de concept. Par contre ici c'est plus les bienfaits du tests en général qui sont mis en avant avec du Test First Approach. En Tdd on va avoir des baby steps (et un seul assert par test), et on n'a plus besoin de console.log ni de passer en pas à pas
Merci sensei tu es le ss4 des codeurs , je suis en reconversion j apprend sur codeacademy et udemy j ai suivi a perte une formation rapide de dev web et web mobile et jamais on m'a parlé de tdd . J en avais eu vent mais sans plus . La je vais enfin pouvoir ajouter une corde a mon arc pour devenir un véritable front end js react redux 😁 Merci 👍
Faut surtout comprendre que les tests servent pas nécessairement à s'assurer que le test qu'on écrit marche. Mais c'est pour s'assurer qu'il continuera à marcher quand un autre gars refactorisera un truc dans 6 mois.
Avec tout le respect du, je pense que comme dit dans un autre commentaire, ce que tu presentes c’est du Test First. Un des tenant de TDD c’est le fait d’ecrire le moins de code possible a l’instant ou on en a besoin. Dans ton exemple cela reviendrait a n’avoir qu’un cas de test (le .toBe(3) par exemple), et a ecrire le code necessaire pour le faire passer (un bete return [1,1,1] par exemple). C’est ton 2nd test, qui lui comportera le .toBe(2) qui va te faire changer la fonction pour passer tes 2 tests. Ca peut sembler stupide (et sur un cas comme celui la ca l’est), mais ca permet reellement, sur des cas plus complexes, d’avoir le moins de code possible, et de pouvoir commencer a faire aussi d’autres tests d’integration, et/ou d’avoir un mockup de ton developement final (bullet tracing).
De manière générale je suis très preneur de formation française de qualité sur le tdd en front-end. Pour allez dans le coeur du sujet, pour moi le véritable atout du tdd et que ça nous change totalement la façon d'aborder un projet. On rentre dans le domaine de la programmation par intention et à mon sens ça fait une énorme différence. Venant du back avec une approche tdd PHP/laravel, j'ai la sensation que c'est plus difficile à mettre en place avec JS. Comment faire du tdd sur de l'asynchrone ? etc... Bref du contenu français de qualité sur ce sujet m'intéresse fortement.
je pensais que c'était plus à la mode d'ecrire les fonctions comme ça et qu'on utlilise de préférence les arrow functions ? pour l'immutabilité c'est ça??
Merci pour tout ce que tu nous fournit comme information ! C’est des pépites !! Petites question, tu peux utiliser l’approche TDD pour tes components en React par exemple ? Tester le render de ton component avant ? Pré-écrire un test pour ton component ça peut-être long non, ecrire tout le html etc..
Merci beaucoup pour cette vidéo ! C'est une bonne initiative de démocratiser la discipline TDD ^^ Par contre, faire très attention car TDD est souvent mal compris. TDD n'est pas une discipline de testing mais de conception comme tu l'as dit brièvement. Mais du coup pourquoi il y a le mot Test dedans ? Le test unitaire (automatisé) est le meilleur moyen connu pour avoir un feedback rapide sur le code de production (une suite de 500 TU se lance en 1s environ). Le but ultime de TDD est de te guider dans la conception et l'implémentation grâce aux tests unitaires automatisés en plus d'éradiquer la peur du changement d'implem. Les tests sont juste le meilleur moyen d'y arriver... TDD est tel un GPS qui t’emmène d'un point A vers B. Si le dev connais la route (feature simple ou déjà réalisé), le GPS ne lui fournira pas une grande aide, simplement le conforter dans ses choix algorithmiques puis lui permettre de les améliorer grâce au harnais de sécu TDD (Le tracé du GPS). Plus tard si le dev arrive dans un endroit où il sent qu'il perd le contrôle, il aura besoin d'un GPS pour lui dire ici tourne à gauche, et là fais demi-toir. TDD prend tout son sens dans la résolution d'un problème complexe. Ici, ton exemple est un peu trop simple. On y perd donc la notion de guide ;) Comme dit Uncle Bob : La seule valeur acceptable du test coverage est 100% ! Et ce n'est pas atteignable, c'est un but à atteindre. 7:12 As-tu des sources sur ces chiffres ? Encore merci pour ta vidéo et tes explications !!
Effectivement ce n'est pas tout à fait du TDD, comme l'indiquait Pierre. Ca ressemble plus à ce que je décrivais sous le nom de 3T (Tests en Trois Temps) il y a quelques temps. Mais à mon sens, c'est mieux.
« Tester c’est douter » et « corriger c’est abdiquer « viennent de deux affiches proposées par commitstrip.com Comme décrit dans un autre commentaire et dans ta réponse, on est à la limite entre deux types de tests. Le TDD est très complexe à appliquer. Les tests servent à tester, designer comme décrit mais cela sert aussi à documenter le code, un test ne ment pas. C’est certain que je suis plus familier avec le backend mais j’imagine que c’est la même chose en frontend. Entk, bonne vidéo d’introduction!
C'est pas parce que tu les as découverts de cette manière que ça vient de là 😅. C'est dans la culture dev depuis bien plus longtemps que CommitStrip ;)
"Tester c'est douter" c'est une blague je pense 😅 Tester c'est souvent bien mais il fait aussi maintenir les tests, sur les projets courts qui ont tendance à changer toutes les deux secondes c'est pas évident car c'est pas motivant Après sur les projets un minimum carré qui durent sur du long terme c'est indispensable 👍
@@MikeCodeur_ Je ne sais pas si utilises Linkedin, mais il y a Pierre qui a fait je pense une bonne comparaison entre les deux dans son post: www.linkedin.com/posts/pierre-criulanscy_saviez-vous-que-les-livreurs-uber-eat-activity-6795736924238753792-Juun
0:33 « tester c’est douter » C’est juste une boutade. J’ai des devs seniors qui me la sortent souvent quand ils codent un truc vite fait et n’ont pas le temps de faire un test (mais savent que c’est pas bien donc blaguent dessus), ces memes devs qui me repetent a longueur journée de bien faire mes tests.
Un développeur qui ne teste pas son code fonce tête baissée vers les bugs ! Faire des tests permet de voir ce qui marche et qui ne marche pas afin d’y remédier le plus rapidement possible dès l’apparition des bugs. Reprendre son code c’est normal pour incrémenter des nouvelles fonctionnalités et les tests permettent d’intégrer des nouveautés en sécurité.
Le paradoxe de l'enfer du salariat , une entreprise impose les testes , les employés sont obligés de faire les testes , un indépendant fait ce qu'il veut si le client ne contrôle pas le processus de production de l'indépendant , donc il est plus sure de passer par une entreprise que par un indépendant. Les clients devraient exiger les fiches de teste. Si cette chaine fait des millions de vue regardées par des clients , alors les clients vont éliminer les profiles qui ne sont pas professionnels avec les fiches de teste , les développeurs web indépendants , c'est un monde je pense anarchique ou bordelique Une entreprise du point de vue du client et pas de la ressource humaine est un moyen efficace de baliser les phases de production C'est un paradoxe que cette chaine rend visible la différence entreprise avec employé contre indépendant au profit de l'entreprise avec employés
Pourquoi tu t'etonnes ==> les mentalités mettent du temps à changer ? je bossais pour un client Assurance le responsable voulait pas entendre parler de tests jusqu'au jour où ils se sont aperçus que ça leur faisait gagner de l'argent et de la qualité a moyen long terme. Je fais des entretiens SSII (trop) manageurs technique en ont rien a faire, Tu dis "archi" : la plupart des gens c'est sauve qui peut. Même ça pourrait être un critère pour pas prendre les dev (on marche sur la tête !).
