Test-Driven Development (TDD) par l'exemple, et en français !
Vložit
- čas přidán 30. 11. 2016
- Fort de 9 ans d'expérience en Test-Driven Development (alias TDD) et architecte en informatique depuis plus de 10 ans, je vous fait partager ici une démonstration de la stricte pratique de cette discipline.
J'essaie ici de vous convaincre d'utiliser cette pratique dans TOUS vos développements.
Je vous conseille aussi d'aller voir également ma vidéo plus récente sur un cas de TDD plus complexe :
• TDD ça ralentit ? Rega...
Pour plus de détails sur mon activité et autres contenus, voir le site Web wealcomecompany.com
Cette vidéo devrait être montrée à tous les étudiants en première année d’info… Bravo !
Franchement Michaël, c'est une masterclass que tu présente ici. Cette vidéo est en or.
Merci !
Hello, meilleur explication que j'ai vue du TDD, même si je n'applique pas la méthode, j'espère pouvoir la tester un jour :)
C'est vraiment très bien expliqué, chaque étape montre son importance afin d'arriver à un code optimisé.
Encore merci.
merci !
Merci beaucoup pour cette vidéo : je connaissais déjà le TDD, mais j'ai ici appris des notions intéressantes telles que la triangularisation du test.
Génial, merci pour ça. Très inspirant et clairement expliqué pour utiliser TDD et aussi combiné avec refactoring.
Pour la première fois et juste à l'instant je suis convaincu du TDD !
Je souhaite pouvoir pratiquer le plus tôt possible.
C'est un cours trés pédagogique et c'est aussi une démo BRAVO
Une très bonne explication pour le TDD .. maintenant les chose deviennent claire pour moi . merci infiniment
Excellente demo de TDD sur le fond et sur la forme. Très clair, agréable à suivre, informatif.
Super vidéo, l'explication est très clair! Merci beaucoup.
Tout simplement génial, merci pour ce partage
Très bien expliqué, bonne continuation!
Super :-) ! Si la moitié des gens que je vois en entretien savait faire ça... On recruterait plus de monde :-) !
Une dernière fois pour tout le monde on répète :
RED > GREEN > REFACTOR
Et on recommence... Et surtout le reste on oublie :-) !
Super!!! Bravo. J’essaierai d'appliquer sur un prochain projet...
Merci pour cette vidéo très explicative :) Bravo et bonne continuation :)
Franchement t'es vraiment fort. C'était super bien expliqué et droit au but. Merci beaucoup!
xStrafez_ c; Merci ;) Il y en aura d’autres, il y en a déjà de dispo sur la chaîne
Superbe démonstration merci.
Super Bravo, clair et precis. Lance nous des tuto Scala et Neo4J aussi
Super explication ! Merci pour cette démonstration
Ta vidéo introduit très bien les choses.
Très bonne vidéo pour commencer le TDD, merci Michaël i
Une excellente vidéo, ça fait plaisir de tomber sur ce genre de contenu !
Un grand merci à toi
merci :)
Vraiment génial, merci pour ta vidéo, j'ai bien apprécié aussi !
merci !!
Vraiment très cool ! Vous êtes beaucoup plus pédagogue que la personne qui me l'a expliqué la première fois.
Merci c'est gentil !
@@wealcome_company Avec plaisir ! J'ai une petite remarque :
On en débattu avec des collègues, et j'étais partisan de dire qu'on crée les méthodes de test à partir de la conception, et ensuite les classes et méthodes testée à partir des tests, mais d'autres disaient que si vous créez les classes et méthodes après les tests :
- Vous ne pouvez pas utiliser les assistants pour créer les classes de tests à partir de la classe à tester (type JUnit), il faut faire "à la mano" ;
- Ce n'est pas logique pour les Test Unitaires Fonctionnels, que l'on doit créer à partir de l'interface (Doc + en-tête).
J'aimerais avoir votre avis !
merci d'avance.
Super explications !
Excellente vidéo !
Très bien expliqué le concept de TDD
Super vidéo. Je connais l'essentiel des tests unitaires depuis un moment mais ta vidéo est suffisamment complète pour pouvoir speed learn le concept. A recommander à toutes les personnes qui n'en ont jamais entendues parler.
J'ai une certif ISTQB donc l'intérêt de la méthode n'est plus à démontrer pour moi.
Par contre, je ne suis pas très poussé dans les tests unitaires. J'entends par là que j'ai très peu pratiqué.
J'ai pu voir une démo par l'oncle Bob lui même qui traine sur YT.
On a ici un truc en français et bien expliqué et surtout qui est dédié au sujet (sinon il faut trouver le moment précis dans la conférence où RCM fait sa démo cf. czcams.com/video/58jGpV2Cg50/video.html pour les intéressé(e)s).
J'aime pas les vidéos longues mais la démo s'y prête. Et puis je code along pour ne pas m'ennuier et réfléchir aux possibles solutions.
J'ai vraiment tendance à prendre des raccourcis comparé à toi.
Le reflexes pour moi c'est de passer direct au modulo pour les cas de test pour 3 et 6. Avec l'énoncé en tête je connais déjà la solution. Je me doute que c'est pas forcément ce qu'il faudrait faire.
Est-ce que là tu fais vraiment toutes les étapes pour les besoins de la démo ou tu te permets d'aller directement à la solution évidente quand tu la vois ?
A ce moment là j'ai déjà toute la solution qui me saute à la tronche.
Par contre au moment de concaténer 1 et 2 ça part sur une idée bien différente malgré le TDD.
J'ai quand même été dans votre sens. Sauf que mon code était différent. J'avais une valeur par défaut pour le max. Les tests ont marchés jusqu'au moment où il a fallut faire un refactor à cause du duplicate.
La question qui se pose : est-ce qu'on privilégie la simplicité à utiliser une API (permettre l'usage de la méthode avec une seule variable mais on a un duplicate dans la méthode generate()) ou un code clean (refactor au max mais du coup on impose le passage des paramètres même si un aurait suffit) ?
EDIT:
Finalement j'ai eu le meilleur des deux mondes avec un do...while...
Merci pour ta vidéo ! Hyper claire !
merci !
Excellente vidéo merci beaucoup !
Merci :)
Je dois dire que les méthodes evaluateNumbers et evaluateNumber, instinctivement, par habitude je les aurais écrites d'emblée, donc le TDD ne m'aurait pas spécialement rendu service pour cela. Je ne suis pas encore totalement convaincu du bien fondé de l'utilisation du TDD pour moi à l'heure actuelle, MAIS je vais essayer de voir ici et là de chercher des exemples qui peut-être me convaincront réellement, j'espère en trouver. PAR CONTRE, j'ai beaucoup apprécié ta méthodologie pédagogique minutieusement pas à pas ET je te remercie grandement pour ton envie de partager généreusement, grâce à toi j'ai un sérieux avant goût de l'idée directrice du TDD. Je vais continuer à fouiller, merci beaucoup grand.
Je te conseille de regarder ma nouvelle vidéo sur le sujet : czcams.com/video/yiCpfd-kz3g/video.html
Le but de TDD c'est justement de ne pas anticiper...donc n'écris pas evaluateNumber d'emblée. Sur des cas plus complexes, on en voit clairement l'avantage.
Regarde si tu le peux mon autre vidéo, qui place la barre plus haute ;) On y voit clairement l'avantage d'un TDD minitieux sans jamais rien anticiper.
czcams.com/video/yiCpfd-kz3g/video.html
Top, merci !!
Excellente vidéo
Merci !
Très bonne explication, on voit bien l'émergence de la généricité.
ou ?
Ne confonds-tu par le fait de vouloir rendre générique une fonction et la généricité ?
La généricité c'est le fait pour une classe donnée de lui passer en argument un type.
Ce n'est pas le cas, mais pas, du tout, ici ...
Exemple Class toto = généricité
méthode toto(prends n'importe quoi et sert à tout) = générique
@@adelkaderchourafi5369 c'est juste une tournure la plus élégante et concise que "d'une solution générique".
@@hubert_c Au risque de paraitre "lourd", même si ça semble pareil, c'est pas la même chose, une solution générique et la généricité.
Enfin bon, bonne soirée :)
Merci chef
Magnifique, merci. Franchement après avoir vu votre vidéo je ne vois plus comment faire sans!
Cependant j'ai une question: est-il conseillé de tout développer en TDD ou faut-il seulement se concentrer sur les functions / objets principaux? Merci
Chouette démonstration du TDD que je connais de nom depuis plusieurs années mais que je n'ai pas encore eu la chance de mettre en pratique. Je vais essayer pour un prochain projet perso :-)
Bon, il y a plusieurs moments où j'aurais été tenté de prendre qques raccourcis comme par exemple directement utiliser le modulo à partir du 6 vu qu'on parle de multiple de 3 dans la spec, mais je comprends la démarche ;-)
remy40 Merci ! Le raccourci auquel tu fais allusion n’est pas un dommage et tu peux le faire.
C’est juste par moment préférer la « Obvious implementation » à la « Triangulation ».
Dans la vidéo, c’est la triangulation qui a été choisie pour ce passage.
@@wealcome_company oui bien sur, là le cas était super simple donc en vrai on écrirait direct le modulo, mais dans des cas plus complexes il vaut effectivement mieux éviter de généraliser trop vite et se retrouver finalement avec du code générique plus compliqué à lire pour, au final, n'avoir que 2 cas spécifiques à gérer par exemple :)
Pour ne pas aller trop vite et se retrouver bloquer (oui oui, bloqué), il faut suivre la transformation priority premise :
blog.cleancoder.com/uncle-bob/2013/05/27/TheTransformationPriorityPremise.html
Merci ;)
✋✋ ✋ Salut, dans cette exemple tu test la parti logique de FizzBuzz mais dans le cadre d'une application mobile par exemple est ce que tu utilise le TDD pour intégrés ce que tu veux implémenter ( ex: vue model controller etc )
2eme question : Avant de commencer avec du TDD est ce que au préalable tu as une architecture de ton application ? ( exit les MVC, MVVM qui sont des patterns de conception )
Une mine d or ta chaine youtube, moi aussi j adore TDD et en tant que dev je l utilise tous les jours
Le TDD expliqué de la plus simple des façons...
Si je peux me permettre une remarque, tes tests ne permettaient pas de refactorer en utilisant les modulo, tes tests ne spécifiaient pas que le 9 devait retourner Fizz, il t'aurait fallu un tests shouldReturnFizzIfNumberIsMultipleOf3()... Ma question est donc de savoir si il est plus pertinent de refactorer au préalable puis de rajouter les tests qui interdiraient cette refacto ... ou je pousse trop?
Bon j'ai dû passer à côté de quelque-chose car pour l'instant, faire tous ces tests m'aurait pris beaucoup plus de temps que de résoudre l'algorithme (que j'ai résolu en 30 min, je suis + que junior, j'ai commencé il y a 6 mois). Peut-être que c'est parce-que je ne connais pas du tout le Java (car je fais du Javascript et donc je n'ai pas tout compris) et que je ne connais pas encore les tests unitaires, ou peut-être que l'exemple est trop simpliste pour voir les bénéfices du TDD ? Probablement tout ça. Je retenterai avec d'autres tuto pour creuser le sujet, mais pour l'instant je suis contente de mon petit algorithme ^^
Tout ça pour ça :) Bon je suis dans tes 1% à 2% qui résoudrait ça sans TDD... ? Je doute fortement que le ratio d'échec soit aussi élevé sur un énoncé aussi simple. Qui connaît le modulo sait immédiatement comment s'y prendre. Mais bon plaidoyer pour le TDD quand même :)
Je le résouds aussi sans TDD.
TDD c'est comme à l'armée : c'est une discipline.
Beaucoup d'entrainements à l'armée sont aisés, voire très aisés.
En situation réelle de mission par contre, on tombe souvent sur des problématiques qui nécessitent tous ces réflexes/automatismes maintes fois répétés en entrainement aisé.
Sur des exemples plus complexes, la magie opère.
czcams.com/video/yiCpfd-kz3g/video.html
Super le tuto merci beaucoup, merci aussi pour m'avoir appris qu'il est possible de creer une methode directement en decoupant une partie d'une autre avec intelijj , par contre je ne comprend pas l'utilité de passer de generate a evaluateNumber
sites.google.com/site/unclebobconsultingllc/one-thing-extract-till-you-drop
Bonjour. Super vidéo. J'aime bien cette approche. Par contre j'ai un peu de mal à la mettre en place dans certaines situations. Je développe des batchs sous Spring Batch. Les processors, reader, writer, tasklet ... utilise des services qui utilise eux mêmes des dao écrit avec Spring Data. Comment mettre en place TDD dans cette situation ? Déja TDD avec des dao en Spring Data c'est mort... Pour les services je n'ai pas le choix de mocker les dao et pour les processors, ... je n'ai pas le choix de mocker les services. De plus je ne sait pas comment tester l'intégralité du job avec cette méthodologie.
Merci :) c'est tout l'objet de mes formations ;) : wealcomecompany.com
Extra
😍😍😍
merci pour cette vidéo. Petite suggestion : la vidéo aurait pu être d'avantage mise en contexte. Par exemple, il est sans doute indispensable, en tout cas si on veut continuer à suivre les bonnes pratiques et garantir un maximum de qualité, d'utiliser le TDD avec une mesure de la couverture de code. Merci encore tout cas d'essayer de montrer que le TDD ne revient juste pas à écrire les tests avant le code.
Merci :) La mesure de la couverture n'est pas essentielle et est juste un gadget. Tant qu'aucun code de prod, ne serait-ce qu'une lettre n'est écrite avant d'avoir un test qui fail, et que tu écris le minimum de code (clean) pour passer le test, t'auras du 100%, pas besoin d'aller checker avec un outil.
Excellente vidéo. En tant que tout débutant en codage j’ai envie de commencer par développer une bonne méthodologie pour gagner du temps dans mon apprentissage. Je débute en codage et le TDD semble peu documenté… Impossible de trouver des explications claires sur l’installation d’un IDE qui prenne en charge le TDD. J’ai atom. Je ne trouve personne qui fait du TDD en python sur atom pour copier ses settings …
Est ce que c’est une méthode de niche que tres peu de gens utilise ? As tu des liens ou des tutos a me conseiller pour pouvoir mettre en place tout ce qui est nécessaire pour coder en TDD ?
Merci pour cette vidéo, c'est très instructif ! Par contre je me pose une question: à plusieurs reprises, vous dites que la TDD vous permet d'avoir un code à la fois optimale et le plus court possible. Dans ce cas, pourquoi subdiviser la méthode generate en plusieurs méthodes privés ? N'est-ce pas écrire du code pour rien et allonger inutilement la taille du fichier ?
Merci :)
Bonne question, plus court ne veut pas dire court en terme de lettres tapées au clavier; mais court dans le sens "Aucun code mort ou code inutile".
Pourquoi subdiviser la méthode en plusieurs méthodes privées ?
Pour auto-commenter ton code (chaque nom de méthode est un commentaire en soi) et pour réussir à obtenir qu'une méthode fasse une seule et même action.
Lorsqu'une fonction fait une seule et même action, non seulement elle est facile à comprendre mais en plus elle est réutilisable.
Cette notion de "split" de méthodes est décrite dans le livre "Clean code" de Robert C. Martin et surtout ici :
sites.google.com/site/unclebobconsultingllc/one-thing-extract-till-you-drop
Tu seras probablement d'accord avec moi qu'une méthode qui fait 15 lignes avec des boucles de partout et plusieurs actions différentes est carrément plus complexe à saisir qu'une série de termes anglais qui décrivent l'orchestration d'un algorithme; à savoir l'orchestration de ces "petites méthodes".
Plus la méthode est haute dans le fichier, plus elle est "orchestratrice"; et donc masquant une complexité algorithmique; implémentée par les "méthodes en-dessous".
En un clin d'oeil, on saisit l'intention du programme et "l'histoire" (en anglais pur !) racontée par le programme.
Donc la longueur d'un fichier (voire même l'extraction de classes) n'est pas du tout une mauvaise chose; bien au contraire; elle est bénéfique.
J'ai réalisé une autre vidéo, avec un exemple plus complexe :
czcams.com/video/yiCpfd-kz3g/video.html
En effet ça fait sens et ça correspond aussi à l'idée qu'un bon code n'a pas (ou peu) besoin de commentaires pour être compréhensible.
Sinon rien à voir mais j'ai eu un entretien avec cet exercice hier après-midi, je me suis rendu compte que trop tard que j'avais fait une bête faute (ma boucle s’arrête une itération trop tôt, je ne comprends pas comment j'ai pu laisser passer à côté d'une énormité pareille), et je crains que le retour de mon entretien soit négatif à cause de ça :/ Je ne connaissais pas la TDD, je ne m'y suis intéressé qu'hier (je lisais des articles sur les PSR et une chose en entraînant une autre je me suis retrouvé à regarder des vidéos sur la TDD), j'aurais bien souhaité découvrir ça plus tôt, ça m'aurait rendu plus efficace dans mes tests. Du coup je suis content d'avoir découvert votre chaîne, mais ça m'a fallu une sale nuit où j'ai peu dormi à cause du stress et de l’appréhension ^^'
T'inquiète pas, c'est encore méconnu pour beaucoup de monde malheureusement.
Mais au moins y'a un point positif que beaucoup n'ont pas eu la chance de palper :
Par "l'erreur" tu t'aperçois ce dont TDD est capable de combler ;)
Je veux m'y mettre dans mes sides projets pour changer de boulot ^^
Excellente vidéo, merci beaucoup!!
Question: Quel IDE utilisez-vous?
Merci ! IntelliJ comme IDE
Je rejoins les avis précédents. Très bonne vidéo ! Merci ! à 40:46 vous créez une méthode avec un morceau de code. Connaissez-vous un équivalent sous eclipse ?
Merci :)
Oui Eclipse le fait aussi (encore heureux :) ) :
help.eclipse.org/neon/index.jsp?topic=%2Forg.eclipse.jdt.doc.user%2FgettingStarted%2Fqs-ExtractMethod.htm
si besoin je fourni la version en swift
15 est à la fois un multiple de 3 et de 15, or ce cas n'a pas été spécifié. Il n'y a pas plus de raisons de renvoyer FizzBuzz que Fizz.
La première réponse à cet exercice, c'est qu'il faut toujours essayer de détecter un maximum de bugs et de flous au plus tôt, dès la spec. Plus un bug est détecté tard, plus il coûte cher ☺️
Et 2ème chose, la spec n'a pas été respectée : la spec ne demande pas de pouvoir paramétrer l'entrée, elle impose de 1 à 100 😁 (tiens d'ailleurs la spec ne précise pas non plus si ces bornes sont inclues ou exclues 😋)
Un autre enseignement de cet exercice, c'est que le métier ne sait jamais ce qu'il veut, et que les BA attendent que les devs leur remontent les problèmes de spec. Et encore on est chanceux, on a eu une spec.
Au delà de ces taquineries, pour ceux qui découvrent le TDD, il faut prendre un peu de recul : pour les cas triviaux comme celui qui est présenté, il n'y a pas besoin de passer 45 minutes. 2 minutes suffisaient pour écrire les tests (à la chaine) puis le code. Ce qu'il est important de retenir de ce vidéogramme, c'est que TDD est une méthode en 3 temps et à petits pas, qui permet à coup sûr de coder une solution qui répond au besoin et en laquelle on a une entière confiance grâce aux tests apportés, qui ont une utilité à la fois pour le développement en cours mais aussi pour toute la durée de vie de l'application :
1) écrire un test (qui va échouer), qui traite d'un comportement attendu
2) écrire du code (qui va faire passer le test correspondant au vert) en allant au plus simple
3) refactorer le code (en se rappelant que le refactoring doit avoir un impact uniquement sur le code, surtout pas sur les comportements qui sont décrits dans les tests.)
Dans tous les cas, TDD ou pas, écrivez des tests !
"15 est à la fois un multiple de 3 et de 15', or ce cas n'a pas été spécifié" => oui vu ainsi on peut se dire cela et c'est un bon point à poser au métier :) Tout à fait d'accord avec ton point.
Et c'est en réalité un (mauvais) raccourci de l'énoncé initial qui lui précise : "For numbers which are multiples of both three and five print “FizzBuzz”" => là il n'y a plus de doute.
"Et 2ème chose, la spec n'a pas été respectée : la spec ne demande pas de pouvoir paramétrer l'entrée, elle impose de 1 à 100 😁" => ceci relève d'un détail d'implémentation (un choix personnel) car l'énoncé "Write a program that prints the numbers from 1 to 100" n'apporte aucune contrainte à ce niveau.
C'est effectivement un cas trivial qui a pour but de démontrer l'intérêt du TDD avec un exemple simple.
Celui-ci est d'un niveau supérieur : czcams.com/video/yiCpfd-kz3g/video.html
"Dans tous les cas, TDD ou pas, écrivez des tests !" => Je ne suis pas de cet avis.
Un test écrit après coup est souvent impossible, je l'explique ici à ce moment précis : czcams.com/video/jxBmKvS7lAo/video.html
De la même façon que des tests écrits à la chaine et avant le moindre code effectif enlève tout le bénéfice de TDD à savoir les feedbacks fréquents et immédiats de la progression.
Et au point 3) : refactorer le code, ET les tests :)
@@wealcome_company tu as tout à fait raison, en fait je voulais juste dire que quand on évolue dans des entreprises où la culture des tests est inexistante, où les projets ont zéro tests (perso je n'ai connu quasiment que ça jusqu'ici), c'est compliqué d'avoir le déclic et d'amorcer cette culture (et même simplement de réussir à écrire un test dans un code qui n'avait pas du tout été pensé pour). Le tout c'est de se lancer, même si ce n'est pas parfait au début et même si ce n'est pas du TDD, car c'est bien mieux que rien, et une fois lancé le TDD nous tend les bras :-)
Merci pour tes vidéos en tout cas, c'est très précieux !
@@julienl.1080 Je suis d’accord ! Et merci pour tes remarques sensées, j’ai beaucoup aimé celle sur le manque de précision de l’énoncé :)
Si on compare à 28:30 et à la fin 46:00, on a exactement la même fonction evaluateNumber. après 28:30, tu la transformes en generate pour au final l’extraire à nouveau et retomber sur evaluateNumber qui fonctionnait déjà.
pourquoi ne pas créer directement la fonction qui appelle evaluateNumber et tester cette nouvelle fonction sans casser ce qui existe déjà ?
À cette étape là on sait déjà que cette fonction est utilisable telle quelle pour le produit final.
anisometropie Benihime Pour garder une liberté de refactoring. On ne teste jamais des fonctions biais (private etc), on teste la fonction principale du use case (méthode publique).
Sinon tes tests seraient trop liés aux détails d’implémentation, à savoir la connaissance de la sous-méthode.
Je n'étais pas convaincu par le TDD en arrivant et je repars malheureusement de la même façon. Ceci dit je trouve que la vidéo met quand même très bien en avant l'intérêt des tests unitaires.
Mes griefs : j'ai l'impression que cette pratique encourage le biais de confirmation, donne une confiance démesurée dans ce qu'on a écrit et empêche d'anticiper, de designer, sa solution avant de l'implémenter :
- 15:40 on convertit `number == 3 || number == 6` en `number % 3 == 0` alors que le passage de l'un à l'autre n'a en fait rien d'évident: si je vous donne une suite de nombres et vous demande de trouver la règle qui a régit sa construction, plusieurs solutions sont la plupart du temps possibles et en formuler une qui fonctionne n'est en aucun cas la garantie qu'on a trouvé la bonne (par exemple : ici avec seulement 3 et 6 ont peut hésiter entre `n => n * 3` et `n => n * (n + 1) / 2`). Du coup on peut se demander : plutôt que de jouer l'idiot en écrivant d'abord `number == 3 || number == 6`, puis faire une généralisation risquée, est-ce que ce n'était pas plus sûr de modéliser rigoureusement la notion de multiple de 3 directement ? Quitte à extraire ça dans une fonction et à faire des tests unitaires dessus (personnellement j'utilise un REPL pour me convaincre que certaines expressions ne méritant pas une extraction fonctionnent).
- J'estime que la solution proposée n'est pas optimale, contrairement à ce qui était promis 0:56 sur les critères suivants : on se retrouve à concaténer une chaîne de caractères 100 fois, ce qui est réputé lent (je ne connais pas Java), à faire 3 modulos au lieu de 2, on a un appel de fonction inutile et aussi on a répondu à un problème plus général que celui qui avait été posé (la fonction prend un range en paramètre alors qu'on veut une suite de 1 à 100). Je crains que cette idée de solution optimale mette le développeur dans une situation d'excès de confiance.
- J'ai le sentiment qu'il est plus difficile d'évaluer son algorithme de façon générale si on a toujours les yeux rivés sur le dernier test et qu'on se retrouve à "improviser" son code étape par étape. Es-ce qu'on ne manque pas de recul ? Où est passée l'étape "papier crayon" : est-ce qu'on n'est pas encouragé à plonger tête baissée dans l'implémentation ?
Merci pour ce feedback.
TDD guide vers une piste cohérente mais pas vers la piste la plus optimisée.
Est-ce pour cela que TDD ne permet pas du code optimisé ? Loin de là, évidemment qu'il le permet !
Pourquoi ?
De 1, TDD n’empêche pas de penser.
De 2, le but ultime de TDD, c'est de permettre de refactorer sans crainte une solution qui répond au bon comportement attendu.
Un refactoring, c'est changer la structure sans changer le comportement.
Ainsi, si tu trouves qu'à un certain stade (toi, ou un autre développeur) a usé de concaténations, et bien tu peux refactorer car tes tests te couvrent !
On peut même transformer tout ce programme avec le paradigme de la programmation fonctionnelle, sans crainte, tes tests te couvrant.
Ça te permet de supprimer tout code mort ou inutile sans crainte et donc d'avoir un algo en béton.
Je te recommande de t'essayer sur cet énoncé, et de comparer avec le mindset TDD que je présente :
czcams.com/video/yiCpfd-kz3g/video.html
"plutôt que de jouer l'idiot en écrivant d'abord `number == 3 || number == 6`, puis faire une généralisation risquée, est-ce que ce n'était pas plus sûr de modéliser rigoureusement la notion de multiple de 3 directement ?" => ce n'est en rien risqué, vu que tes tests te couvrent lors de l'émergence de ton code, c'est tout le principe. Tu peux si tu le souhaites passer directement au modulo, mais ne pas aller trop vite est la recommandation de la discipline :
Je conseille cet article : blog.cleancoder.com/uncle-bob/2013/05/27/TheTransformationPriorityPremise.html
"à faire 3 modulo au lieu de 2" => Les 3 modulos sont obligatoires, auquel cas le programme ne fonctionnerait pas comme attendu.
"Quitte à extraire ça dans une fonction et à faire des tests unitaires dessus" => on ne doit pas tester les "internals". Un tel test serait fragile car casserait au moindre refactoring de la solution.
On teste toujours par les APIs des modules (méthode publique d'entrée).
Je vous cite : "Plusieurs solutions sont la plupart du temps possibles et en formuler une qui fonctionne n'est en aucun cas la garantie qu'on a trouvé la bonne" => tout à fait, TDD ne guide pas vers la meilleure solution, mais vers une solution qui fonctionne et qui pourra donc se faire refactorer sans crainte.
Je recommande ces 2 articles : blog.cleancoder.com/uncle-bob/2016/03/19/GivingUpOnTDD.html et blog.cleancoder.com/uncle-bob/2017/03/03/TDD-Harms-Architecture.html, qui d'ailleurs répondent à ce que tu dis : "est-ce qu'on n'est pas encouragé à plonger tête baissée dans l'implémentation"
Merci pour ta réponse. Tu peux être sûr que je vais me jeter sur tes liens.
Concernant le refactoring, je pense qu'une fois que l'implémentation est amenée à un point p et à un moment t, dès lors qu'on a des tests qui couvrent chaque boundary, on a notre filet de sécurité et on peut faire du refactoring en toute tranquillité. La méthode qu'on a suivi à un temps t - n pour arriver à un point p - x ne change rien à ce fait. D'après ce que j'ai compris, le TDD c'est cette procédure de progresser dans la complexité de l'implémentation étape par étape avec une implémentation naïve qui satisfait strictement chaque étape, écrire des tests unitaires n'est pas spécifique au TDD.
Je pense que `number == 3 || number == 6` -> `number % 3 == 0` est objectivement risqué car l'opération n'est pas un refactoring (changement de structure pur) : ce n'est pas comme si tu avais factorisé quelque chose, supprimé un calcul qui se simplifie, utilisé une règle d'associativité, d'identité, de composition, etc. C'est une modélisation différente qui repose sur un ensemble d'hypothèses que tu évalues via heuristiques. C'est un processus faillible (et c'est d'autant plus traître qu'on n'est souvent pas capable de se relire dans ces cas là parce que justement on tient l'équivalence pour acquise et notre oeil glisse dessus). Aussi, ça veut dire que tu te fais confiance pour déclarer "dans le cadre limité de mon problème, ces deux expressions sont équivalentes", or dire ça requiert d'avoir le champ complet du problème en tête, ce n'est pas toujours possible. (Parenthèse : si tu ne testes que l'API publique, tu peux ne te rendre compte que tardivement que les deux expressions ne sont pas équivalentes).
Concernant l'extraction et le problème de tester les "internals" : je suis tout à fait d'accord sur le principe, mais si la fonction que tu extrais est une fonction pure générique (comme c'est très souvent le cas en programmation fonctionnelle et comme c'est le cas ici), c'est pratiquement un élément d'une bibliothèque et il ne me semble pas déraisonnable de tester une bibliothèque. Il ne s'agit pas de tester si la fonction est appelée mais si elle fonctionne en isolation, donc si elle n'est plus appelée elle ne peut pas faire échouer de tests. Si elle doit être remplacée elle sera marquée comme dépréciée et sera éliminée à terme.
Concernant les 3 modulos : si tu stockes le résultat de `n % 3 == 0` et `n % 5 == 0` dans des variables, tu peux tester `a && b` au lieu de `n % 15 == 0`. Ça te fait calculer 2 modulos 100 fois au lieu de 3 modulos 67 fois, 2 modulos 27 fois et 1 modulo 6 fois. Ce n'est pas une optimisation magique et ça reste lisible.
@@ApprendreSansNecessite Comme tu le soulignes à ta manière, TDD est une discipline de fer qui profite du caractère alarmant inhérent à tout test unitaire pour te guider pas à pas et sans labeur vers le bon code à produire, tout en justifiant l’existence de chaque caractère de celui-ci.
Il y a une règle précise en TDD : As the tests get more specific, the code gets more generic.
number == 3 est bien moins "générique" que number == 3 || number == 6 et bien moins que number % 3 == 0.
Ce n'est donc pas réellement un refactoring sans effet actif, vu qu'il ouvre le champ des possibles.
Mais c'est tout de même dans cette phase de refactoring en PLUS de la phase green où il est recommandé de générifier dans un contexte de 'triangulation' ; c'est tout le principe du TDD avec cette triangulation : avoir deux tests qui matérialisent, naïvement quelquefois, un concept sans effort avec le mécanisme "fake it until you make it" (le 3 et 6) pour ensuite permettre de valider une générification rendue possible par ces deux tests (mettre % 3 et regarder si ces tests passent toujours).
Le fait d'appliquer la triangulation permet de voir dans des cas difficiles/subtiles, noir sur blanc, les similitudes de résolution et ainsi de commoniser/abstraire/générifier des notions.
La phase Green du TDD (passant le test une première fois) amène une "généricité" au programme dont le but est l'adaptation à une nouvelle spécification ; on parle d'évolution de l'algorithme affinant celui-ci à la sphère réelle du problème.
Et la phase de Refactoring quant à elle peut étendre ou contraindre les possibilités du problème par le biais d'une "clôture" d'aspects triangulaires hard-codés matérialisée par la générification supposée et prétendue du problème.
On ne parle donc pas d'expressions équivalentes mais d'expressions inclusives (ici % 3 inclus les autres (3 et 6)).
Cette règle du % 3 a été induise par l'aspect "thinking" de TDD et la triangulation, cette phase où l'humain pense et palpe une généralité d'étage de niveau directement supérieur, couvrant les précédentes exigences pour introduire les nouvelles et nombreuses de même et exacte nature (même notion comportementale mais juste le jeu de données qui changent/s'accroient) : le fait que le nombre soit un multiple de 3. Et oui, Ron Jeffries (pionnier également du TDD) dit bien : "Act locally, think globally".
En effet, on ne va pas écrire un test unitaire pour CHAQUE nombre répondant à cette chaîne "Fizz".
Ce serait absurde.
Du coup on "think" pour générifier légèrement à partir des aspects triangulés nous dirigeant vers le supposée bonne évolution de la solution, supprimant des duplications hard-codées dans notre code.
C'est une hypothèse de générification évidemment car ce genre d'exercice n'a pas de limites dans les variantes d'inputs possibles.
Mais de la même manière que sans TDD, le raisonnement humain peut être biaisé si l'on ne prend pas bien en compte les profondeurs du problème.
En revanche, il existe une pratique qui s'appelle Property-Based Testing et qui est tout à fait complémentaire au TDD pour ce type d'exercice à inputs infinis.
Cette pratique permet de générer intelligemment une multitude d'inputs à la volée et de valider un axiome (à la charge du développeur de trouver cette axiome, notamment pour le FizzBuzz), car oui, on ne peut plus dans ce contexte d'avalanches de données valider un état figé mais une règle générale ciblée. C'est encore un mode de pensée différent mais complémentaire sur ce genre d'énoncé dealant avec l'infini des possibilités, permettant de valider des hypothèses tout de même fortement probables d'être justes.
Ok avec toi pour la fonction générique testable de manière isolée, mais ici il n'y a aucune notion générique qui peut/doit exister de manière totalement indépendante du FizzBuzz. Tout émerge à partir d'un énoncé bien particulier, donc il convient de tester le comportement du module en lui-même et non de sous-parties.
Tester des sous-parties de manière isolée grave en quelques sorte dans le marbre les décisions de design du module.
Or celui-ci doit pouvoir être sujet à un refactoring même conséquent, sans pour autant sans la signature du module, point d'entrée du client, auquel cas on perdrait cet aspect que prône le TDD : le "continuous improvement".
Ok pour les 3 modules si effectivement tu passes par des variables locales, mais sache que justement tu es totalement légitime à refactorer le code émergé à un instant t pour te débarrasser d'un concept en "trop" ou inutile, toutes tes séances de refacto seront des moments de plaisir, de beau ménage ET dans la sérénité la plus parfaite : sérénité que tu ne peux obtenir sans TDD.
Je te conseille cet article : sites.google.com/site/unclebobconsultingllc/home/articles/as-the-tests-get-more-specific-the-code-gets-more-generic
La notion de la progression "spécifique -> générique" est le coeur de l'essence du TDD et ce qui je pense répondrait à pas mal de tes remarques.
@@wealcome_company C'est beaucoup plus clair et ça ouvre plein de pistes de réflexion.
Je suis toujours perturbé par un truc : Dans ta vidéo tu ne verbalises pas une modélisation générale de la solution, il n'y a pas cette étape de design, ce serait justement le côté magique du TDD. On a cette impression que le TDD c'est un peu comme une descente de gradient centrée sur l'API où on progresse de proche en proche dans une direction, et on peut se demander légitiment si cette procédure ne fait pas tomber systématiquement dans un minimum local : si l'ensemble des solutions est totalement traversable en TDD.
Je vais prendre un exemple : en théorie des catégories (un standard assez lisible est dispo sur github/fantasyland/fantasy-land), si on cherche à implémenter un type algébrique particulier, il ne suffit pas que l'API fonctionne : on peut tout à fait écrire une implémentation dégueulasse des méthodes requises et qui passerait tous les tests d'API auxquels on peut penser sans que le type qu'on a construit soit légal et ait les propriétés recherchées, et ça on ne s'en rend compte que si on veut inter-opérer avec un type de plus haut niveau ou implémenter d'autres méthodes de plus haut niveau (donc on se rend compte que notre type est faux dans une étape ultérieure et facultative) : en fait chaque méthode doit répondre à des lois (associativité, composition, homomorphisme, etc.) qui ne sont pas dérivables de l'API, et il y a certains interdits (ne pas tester le type d'une sortie ou d'une entrée par exemple). J'ai l'impression que parce qu'on a toujours un temps de retard sur la spec en partant de l'API, une implémentation en TDD se traduirait par réécrire toutes les méthodes de zéro quasiment à chaque test pour satisfaire une nouvelle propriété ignorée. La TDD interdit d'anticiper. Es-ce que tu trouves cette interprétation abusive ?
Tu m'as presque convaincu pour le modulo. Effectivement, si on le testait en isolation on testerait qu'on sait exprimer un multiple de 3, pas que c'est bien d'un multiple de 3 qu'on a besoin pour implémenter fizzbuzz. Le truc c'est que la notion de multiple de 3 elle est dans le cahier des charges, donc en fait la difficulté est bien d'implémenter le multiple de 3 correctement. Est-ce que ça mérite un test ? je ne pense pas ici mais on voit bien que la méthode TDD t'a fait passer par des étapes inutiles pour chaque modulo.
@@ApprendreSansNecessite Il faut distinguer deux choses : le design local et le design global.
TDD n'aide en RIEN au design global.
Le développeur est obligé de penser la solution globale "est-ce une bonne stratégie de passer par des multiples de 3 ? Est-ce une bonne stratégie de réaliser un tri par fusion plutôt qu'un tri bulle pour résoudre cet algorithme ?"
Une fois que notre décision globale est prise, là s'enchaîne la réflexion au sujet de la bonne trajectoire des tests, permettant une approche de designs "locaux" à émergence incrémentale (suivant la transformation priority premise) : medium.com/@zolipeto/extract-of-uncle-bobs-transformation-priority-premise-post-85ab20216fb1
Ainsi lorsque tu définis de nouveaux types algébriques (en FP), tu te DOIS de penser avant de commencer sinon tes actions locales mèneront à une incohérence au niveau global, t'éloignant alors des contraintes/spécifications requises des propriétés de ce type (monoids (associativité/commutativité) / degré de généricité / nature de contravariance / nature de covariance, etc).
Mais une fois que tu as ces décisions, grâce au stylo/papier si tu le souhaites, tu peux rédiger ton code en TDD, suivant ton fil directeur de pensée bien établi.
En FP, on complète souvent avec le property-based testing comme évoqué plus haut pour vérifier les propriétés/comportements de tes types algébriques. Le TDD restant le moyen le plus efficace de driver l'implémentation par à-coups intelligents à partir de certains jeux de données angulaires, issus donc de ton fil directeur de pensée.
En résumé, TDD est excellent pour driver ton implémentation et le DEV lui se doit d'être excellent pour réfléchir à la bonne direction à prendre.
Autrement dit, il faut éviter d'anticiper l'implémentation et donc les successions de design "local", mais il faut anticiper le design "global" et les choix stratégiques de la solution.
TDD est magique (je peux le confirmer, je pratique à 100% depuis 10 ans dans tous mes projets), mais comme tu l'auras je pense compris, requiert tout de même une bonne analyse du problème global en amont, une découverte du bon fil directeur.
La magie de TDD, si transformation priority premise bien respectée, te permettra toujours de découvrir un design local, concis et précis qui marche.
Et si tu veux optimiser ce code => refacto sécurisé par le fait que chaque lettre que t'auras produite aura eu son existence justifiée par les tests et la discipline TDD ;) Tes tests sont donc à 100% superposés (même si de nature différente) à ton code et tu peux donc modeler celui-ci à ta guise pour passer d'une solution qui marche à une solution optimale.
je l'ai écris différemment avec le pattern chain of responsability, comment tu testerai ce genre de fonction qui retourne void ? Comment tu écrirai une fonction bouchon ?
Peux-tu copier/coller ton code sur un gist stp ?
gist.github.com/bouazaoui/919693adafb71f3e9dff52e77d481f18 je l'ai ecris en C# , si tu veux , je le réecris en java.
en java : gist.github.com/bouazaoui/5c3e141e5af7da64fffe73b140f4a6ba
a bouaz Ta fonction principale ne retourne pas void mais string, donc de la même manière que je le fais dans ma vidéo.
Un test unitaire cible l’api publique d’un use case, jamais des méthodes d’implémentation de celui-ci.
La méthode main ne fait pas parti du use case, elle APPELLE le use case et ne doit donc pas être testée.
Elle délègue juste l’intelligence au use case.
Utiliser le pattern chain of responsibility est totalement overkill et complique grandement la solution dans ce cas-là.
De plus, à proscrire l’usage du français dans le code :) Le franglais est illisible :)
je pensais également la même chose, ça ne sert à rien de faire du coverage de code à 100%.
desfois l'anglais ce n'est pas évident, on utilise parfois des mots qui pour certains cela peut vouloir dire autre chose, le français dans le code c'est mon gros defaut.
Sais tu que la syntaxe du windev, le WLangage , c'est du français ?
Question :
Je pensais que si on met 2 en entrée :
On doit retourner les entiers de 1 à 2 donc résultat attendu : "12" ? Ou j'ai mal compris l'énoncé ?
Regarde la vidéo en entier, je pense que ça répondra à ta question :)
@@wealcome_company j ai pas encore terminé j'essayais dans mon coin lol ^^
en tout cas c'est super cool ^^
Merci :)
@@supershinjin1441 merci :)
Hello World.
Un peu hors sujet : Aucun commentaire sur la concaténation de chaîne !?
Un programme qui fonctionne c'est déjà bien, optimisé c'est encore mieux.
Personnellement, je trouve que 90% c'est un peu surgonflé.
(il faut avouer :p ou alors il y a vraiment des différences dans les régions/entreprises.).
sinon bravo pour l'évangélisation ;-)
Jimmy Pannier Rien ne t’empêche de refactorer sereinement grâce aux tests ;)
@@wealcome_company J'utilise un outil de qualimétrie que forcément tu connais (SonarQube) avec règles assez strictes. Jenkins, l'outil d'intégration continue impose une Quality gate à 80%. (couverture de code). Donc j'en mange ;-)
@@jimmypannier5720 Je te recommande mon passage à exactement 1h41m:20s : czcams.com/video/jxBmKvS7lAo/video.html .
Ça rejoint l'idée que la couverture de code peut être bien trompeuse sans pratique TDD (SonarCube ou non).
Hello. J'aime bien le TDD. Mais les gens échouent à cet exercice sans ça ??
Faut croire que tout le monde n’a pas un cerveau assez développé…
Il faut se remettre en question si on arrive pas à réussir fizz buzz sans tdd et en moins de 5 min et 16 ligne
Edit :
Je voulais être méchant parce que la c'est pas possible
En tout cas vidéo très intéressante et merci
Il y a bien du code inutile, faire un modulo 15 alors que 15 est multiple de 3 et de 5 c'est du code inutile et modulo est une opération extrêmement gourmande.
De plus depuis quand écrit-on une fonction ou une méthode avec plusieurs return?
Votre vidéo m'a convaincu du fait qu'il sera toujours plus performant de réfléchir et d'écrire un algorithme avant de se lancer dans l'écriture du code et que faire du TDD est le meilleur moyen d'arriver à un code médiocre.
Je ne suis clairement pas d'accord avec tout ce que vous dîtes mais vous être libre de le penser.
Un code avec plusieurs return n'est clairement pas mauvais, au contraire, il évite le réassignement de variables.
Tentez de résoudre l'algorithme sans "modulo 15" et avec un code plus performant en Java et on comparera.
Exacte 15 est bien un multiple de 3 et 5 mais ne donne pas le même résultat à savoir 'FizzBuzz'. Comment auriez vous solutionné ce cas du coup ?
Pouvez-vous donner un article disant qu'il est mauvais de faire plusieurs return ? Et qu'elle serait la bonne solution selon vous ?
Alors faut savoir : soit le modulo est coûteux et dans ce cas-là on est cohérent et on sort une solution sans modulo :) soit on admet que c'est obligatoire dans le cadre de ce programme.
Je préfère 100 fois l'approche fonctionnelle qui consiste à ne pas réassigner de variable.
Donc plusieurs returns sont 10 fois plus clean et respectant ce principe plutôt qu'un seul.
Expliquer pourquoi l'approche fonctionnelle (functional programming) est meilleure est un autre sujet.
Le fait d'utiliser plusieurs return dans une fonction est une mauvaise pratique de programmation dans ce cas là car il vous conduit à ne pouvoir utiliser le résultat du test modulo 3 dans le test modulo 5 ce qui vous oblige donc à faire un test modulo 15 totalement inutile.
En revanche utiliser des return multiples peut être intéressant pour clarifier une synthaxe if elseif else mais c'est bien le seul cas.
Pour le stocker le résultat du modulo Ok, mais le return ne retourne pas le résultat du Modulo dans notre cas, mais la chaîne générée.
Et le problème de réaffectation est au niveau de la chaîne et non au niveau du modulo.
Donc cette argumentation n'est pas valide.
Pas fan du fait d'écrire un test pour une classe, ça rend la refacto plus compliqué lorsqu'il s'agit de changer l'architecture du code. Faire un test par fonctionnalité permet de ne pas avoir à renommer les tests. Aussi, l'un des intérêts du TDD est de "découvrir" le design, là tu sais d'office l'archi que tu vas avoir et ça peut mener à d'autres soucis :)
Bonne vidéo sinon, ce serait intéressant sur un exemple un peu plus "real world".
Pour un exemple plus real world, voir mon autre vidéo : czcams.com/video/rYX51DaJifw/video.html
Dans la vidéo du FizzBuzz (de cette page), je ne fais clairement pas de tests par classe, mais par comportement.
Je ne cible que l'API publique du use case, à savoir la méthode "generate".
J'avais répondu à une question justement à ce sujet : stackoverflow.com/questions/21482602/should-i-write-tests-for-class-a-if-its-covered-from-class-b/21482748#21482748
Si tu remarques bien, je ne fais clairement pas de tests par classe, car je peux très bien extraire un "evaluator" en extract class, sans tester celle-ci puisqu'elle est déjà couverte par le test. D'où la liberté dans le refacto.
" là tu sais d'office l'archi" => faut bien avoir un point d'entrée. La seule chose qui a été créée d'office c'est la méthode "generate" (API publique), rien d'autre. Tout le reste est flexible et découvrable.
Bonjour Michaël.
Essayons une critique constructive.
Un risque avec cette vidéo : le problème utilisé pour illustrer étant très "jouet", un auditeur qui n'est pas *déjà* conscient *et* convaincu des bénéfices de la méthode en usage réel risque de *totalement* passer à côté du propos, ne même pas le voir.
À la lecture, on voit l'application stricte de règles mais sans les avantages qu'elles auraient en situation réelle. Cela inciterait presque à des critiques telles que "if(number==3 || number==6) n'est pas plus court que directement que if(number%3==0)" ou bien "sur ce problème simple (oui, le fameux fizzbuzz) je serais allé plus vite en n'écrivant aucun test".
Je sais, cette dernière critique serait passer à coté du propos mais je crains que cette vidéo de presque 47 minutes ne convainque que des gens déjà convaincus, impression corroborée par les premiers commentaires.
Peut-être une vidéo plus courte sur une situation plus complexe réellement expérimentée, plus vendeuse aurait-elle plus d'impact en pratique ? Pas facile d'exprimer en vidéo les bénéfices exprimés en mots sur butunclebob.com/ArticleS.UncleBob.TheThreeRulesOfTdd .
Stéphane Gourichon J'ai choisi cet exemple car lors d'une précèdente mission, j'ai challengé 6 développeurs avec ce FizzBuzz.
Au bout de 35 minutes, ils n'avaient toujours pas le bon résultat ...
Je ferai un exemple de situation bien plus complexe avec un algo plus astucieux à trouver.
À 6 développeurs il n'ont pas réussi à trouver ça ? (il y a plus optimisé mais c'est simple [Je précise je suis à 5 min 24 quand je publie ce commentaire]).
//Declare all possible exceptions
let handleExceptions = (myNumber:number) => {
let cases = [3, 5, 15];
let casesReplacement = {3 :'Fizz',5 :'Buzz', 15 :'FizzBuzz'};
let found = '';
for(let aCase of cases){
if(myNumber % aCase==0){
found = casesReplacement[aCase];
}
};
return found != '' ? found : myNumber.toString();
};
//Loop over 100 numbers and replace multiples of tracked numbers (3,5,15)
let composeSentence = () => {
let finalSentence = '';
for (let i = 1;i < 101; i++) {
finalSentence += handleExceptions(i);
};
return finalSentence;
};
//Call My Function
composeSentence();
Et si maintenant je te demandais d'avoir une solution purement fonctionnelle, c'est-à-dire sans aucune mutation de variable (e.g finalSentence += handleExceptions(i);), pourrais-tu la refactorer sans être sûr de rien avoir casser ? Sur des problèmes un chouia plus complexe, non. Une suite complète de specs (tests), permet de refactorer sans crainte incrémentalement.
Bonsoir. L'algo ci-dessus remplace 15 par Fizz (observé) et non FizzBuzz (attendu), n'est-ce pas ?
Effectivement Stéphane, en voilà une belle démonstration ;) C'est un algo qui était sur le point d'aller en prod (celui de Jean-Donald), et qui au final, est erroné subtilement.
C'est exactement le point de TDD : éviter les erreurs subtiles.
Tout ça pour ça ?!!! Le principe est clair et bien présenté. Mais je ne suis pas du tout convaincu ni de l'utilité ni de l'efficacité.
petitpoidferoce faut pratiquer pour s’en rendre compte. Regardez les autres vidéos de la chaîne pour vous faire une meilleure idée, ainsi que notre article : wealcomecompany.com/blog/pourquoi-tdd-indispensable-dans-vos-projets-wealcome
90% du temps à déboguer, euhhhhhh non !!!
c'est pourtant ce qu'il se passe souvent en entreprise
En java peut être.
En dotnet on est bien meilleur :P
C'est valable pour le meilleur des programmeurs sur des projets complexes.
butunclebob.com/ArticleS.UncleBob.TheThreeRulesOfTdd
DotNet meilleur ? C'est une bonne plate-forme mais je dois témoigner avoir du reprendre du code C# mal écrit et passé une éternité (variable selon les cas) sous débuggeur à comprendre comment le programmeur avait fait son truc qui marchait si mal. @PascalROZE Qu'est-ce qui ferait que C# protégerait de "90% du temps à débugger" alors que Java non ?
Ce nombre est absolument vrai voir pire mais ce n'est pas vraiment du debugging, plutot lecture de code et comprehension de l'existant puis modofication. Sur cette tranche de 90%, on passe au moins 80% de temps a lire du code... du temps de perdu au final.
moins de 5min
```python
def trois(nbr):
return nbr % 3 == 0
def cinq(nbr):
return nbr % 5 == 0
def quinze(nbr):
return nbr % 15 == 0
#main
for i in range(1, 101):
ok = False
if trois(i):
ok = True
print("Fizz", end='')
if cinq(i):
ok = True
print("Buzz", end='')
if not ok:
print(i, end='')
```
La prononciation est (à lire en français) :
-> test driveune divèlopemeunte
C’est « dri-veune » pas « draille-veune »
😊
yes je sais :)
À l'époque (2016) je disais draïven, dès 2017 je disais driven.
@@wealcome_company 😃 tu es développeur en ce moment et tu utilises le TDD dans ton travail ?
@@casualgamer--7dsgrandcross607 Oui 100% du temps ;)
Donc le tdd c'est de prétendre être complètement stupide.. et refaire le travail 15 fois jusqu'à que ça fonctionne ! Je vois
L'exemple est très mal choisi
pourquoi ça ?
Et que penses-tu de celui-ci ? czcams.com/video/yiCpfd-kz3g/video.html
@@wealcome_company l'explication est claire, mais l'exemple démontre que c'est très lourd de mettre en place le tdd, et que ça demande bcp de temps, bcp peuvent directement écrire le programme et développer son test plus rapidement
regarde mon autre vidéo que je t'ai mise en lien et tu penseras sûrement l'inverse ;)
ou encore ma série en 3 épisodes sur un cas concret d'entreprise :
czcams.com/video/HbF4MAr0kk8/video.html
pas convaincant
Ça dépend pour qui :)
un conseil pédagogique ... oriente tes tuto vers un seul objectif pédagogique. Bien que j'ai apprécié ta video, tu m'a perdu avec le nombre d'argument que tu passes etc ..
nombre d'arguments ? c'est-à-dire ? explicatifs ?