BDD, DDD, ATDD et TDD expliqués !
Вставка
- Опубліковано 29 лис 2024
- Michaël AZERHAD de la société WealCome est l'invité de Numendo aujourd'hui !
Les quiproquo, ennemis numéro d'un projet informatique !
Comment les identifier ?
Comment les prévenir par les biais de conversations et de techniques ?
Michaël présente à travers son humour et des exemples précis les 4 pratiques phares de l'artisanat logiciel et les liens qui les unissent :
BDD / DDD / ATDD / TDD
À voir !
Pour découvrir les prestations de WealCome, experte au niveau de toutes ces pratiques : wealcomecompan...
![[SC] Démystifions le Domain Driven Design - Maxime Sanglan-Charlier](http://i.ytimg.com/vi/O2X7fH043gk/mqdefault.jpg)
Cette vidéo c'est un délice intellectuel, une gourmandise de l'esprit. C'est magique. Bravo Michael :)
Wow merci Lior !!
Merci de publier une telle conférence! Il faut que les développeurs soient plus conscient que ces concepts existent et cette vidéo les introduits parfaitement. On se rend compte de l'étendue des connaissances à acquérir pour améliorer l'état du logiciel actuel.
Merci pour cette conférence, très enrichissante, et a bien challengé mes positions sur différents sujets (TU, TDD, etc.). Merci :)
super vidéo, 2h30 qui passent très vite, merci pour ce contenu =)
Superbe.
Merci pour cette présentation simple et riche d’enseignements.
Tu m’as convaincue.
Merci !
Excellente vidéo, une excellente pédagogie.
C'est très clair, et animé avec passion, bravo à toi.
Merci !
Superbe conférence donnant l’envie d’essayer ! Un autre inconvénient de taffer sans avoir vu l’ui avant est qu’il est plus facile pour tout le monde d’imaginer des features avec un visuel. Concevoir l’ui après avoir validé ce qu’on pensait être les features engendre fatalement une révision de certaines features voire l’ajout ou suppression de features qui peut aussi retarder les échéances et les fameuses estimations
C'est exceptionnel, merci encore !
J'ajouterai ceci à mes propos dans la vidéo concernant la question posée à 2:30:18 :
"En TypeScript, on a des interfaces, donc facile d'abstraire matérialiser les ports (clean architecture) par des interfaces; mais en Javascript on fait comment ? Comment abstraire ?"
La réponse est en fait très simple et n'a pas lieu d'être; si bien que ça ne m'avait pas traversé l'esprit sur le coup :) :
PAS BESOIN DE FACADE encapsulante, pire la façade impliquerait un couplage ...
En Javascript, tout objet A possédant un set X de properties peut se substituer à un objet B possédant un set X de properties.
Un exemple :
const usecase = ({dependencyA, dependencyB}) => dependencyA.add(dependencyB.build())
Ici, les contraintes sont que dependencyA DOIT avoir une méthode/fonction add(something) et dependencyB DOIT avoir une méthode/fonction build().
Ainsi on peut passer pour chaque paramètre tout objet présentant ces méthodes/fonctions.
Exemple de 2 Adapters (implémentations des dépendances requises par le use case) :
const customUseCaseDependencies = {
dependencyA: {add: (something) => {....}},
dependencyB: {build: () => {return "something"}
}
Ainsi, on peut appeler le use case comme ceci :
usecase(customUseCaseDependencies)
et nous constatons donc que le use case n'est donc pas couplé aux implémentations qu'il utilise; un jeu d'enfants ;)
Hope that helps ;)
je suis Michael sur linkedind, au début, je me disais que ce mec est trop arrongant mais je me rends à l'evidence qu'il est extrement bon et talentueux. J'adore, cette video est un regal pour tout developpeur qui veux sortir des chantiers battus.
En l'ecoutant, on sait qu'il maitrise son sujet comme disait Jordan: "work ethics eliminate fear".
Michael quel est le meilleur(s) livre(s) que tu conseil pour connaitre d'avantage le TDD.
Merci !
Je te conseille le livre Modern C++ programming with Test-Driven Development, ne te fie pas au titre, fais-moi confiance.
Très intéressant
Svp est ce quon peut avoir la presentation pour suivre la demontration ?
Bonsoir je t'ai connu via un podcast sur le dev , je voulais avoir les référence des livres informatique que tu as lu . Merci
Merci pour la vidéo :)
Excellente vidéo mais pour un développeur junior, c'est assez complexe à comprendre, surtout la fin 😅
Salut!, j'ai regardé pas mal de tes vidéos, c'est vraiment intéréssant.
Tu aurais des livres que tu conseils? merci
Merci :) , je recommande IDDD de Vaughn Vernon, TDD by Example de Kent Beck et Microservices Patterns de Chris Richardson.
Merci Michaël TOUT remettre en perspective et d'inverser la vapeur!
Merci c'est vraiment tres instructif. Je ne comprends pas tres bien la notion de triangulation. Peux tu expliciter ou la définir stp?
Merci Mafal lo.
TDD est une discipline qui implique un code minimaliste (pas de code mort, pas de code inutile).
Prenons cet énoncé :
Tu dois retourner le montant en TTC à partir d'un montant HT.
Soit le premier test unitaire :
"shouldSwitchFromHTToTTCValue" { int htValue = 2; assertEquals(2.392, switchToTTC(2)); }, ou 2.392 correspond au TTC avec une TVA de 19,6%
L'implémentation du code de prod pour faire passer ce test sera tout simplement par exemple :
"return 2.392" , bel et bien codé en dur.
Pour GENERIFIER cette solution et permettre à la logique métier de traiter un autre montant que "2", il faut alors un autre test, qui contrecarre :
assertEquals(3.588, switchToTTC(3))
L'implémentation se doit alors d'être générifiée pour que les deux tests passent, car ils se marchent sur les pieds ! :
"return amount + amount*19.6/100;" ou amount est donc la variable passée en paramètre de la méthode.
La triangulation est une discipline très stricte qui sur des cas plus complexes permet de coder en toute sérennité car guider ENTIEREMENT par les tests sans jamais anticiper un code de prod ou le générifier potentiellement trop rapidement.
La triangulation est alors l'art d'avoir 2 exemples qui pointent le même concept (se marchent sur les pieds), en vue de générifier une solution.
Vers 1h45 vous mentionnez un logiciel qui "change" le code pour voir si le test est toujours valable. Pourriez-vous me dire lequel est-ce ?
pitest.org/
Très clair, ça rejoint effectivement un peu tout ce qu'on peut trouver dans les différentes présentations anglophones !
Une question demeure cependant, j'ai tendance à ne pas faire de TDD pour l'UI, car ce sont des tests fragiles. Cependant il reste nécessaire de devoir tester des composants react genre "si on fait ça alors ça doit s'afficher, etc.", mais ça reste du test a posteriori dans ce cas n'est-ce pas ? En gros ma question : à quel moment tu commences à écrire des tests pour l'UI, et pour tester quoi ? Certains "gourous" du ATDD vont jusqu'à dire qu'avant les tests unitaire de ta core logic tu commences par écrire des tests de l'interface utilisateur mais à travers un Page Object pour t'abstraire de l'UI. Ce qui me semble instaurer trop rapidement l'UI dans le process de dev à mon goût...mais qui semble être quand même mise au goût du jour aujourd'hui par les méthodologie de dev UI-first par exemple...Quel est ton avis là dessus ?
Merci Pierre et bonne question.
Beaucoup de personnes pratiquent l'ATDD en partant de l'UI, c'est une erreur monumentale à mon sens (et au sens d'Uncle Bob également pour ne citer que lui); même si des ouvrages comme "Growing Object-Oriented guided by tests" de Steve Freeman et Nat Pryce mettent en valeur cette approche par l'UI.
La raison est la suivante : Coupler son Gherkin à des notions techniques tels que l'UI ou des Rest APIs est la meilleure façon de masquer l'essence des règles de gestion, dénaturer le langage ubiquitaire, et complexifier sa lecture par les stakeholders. Sans compter évidemment le fait que, comme tu le précises si bien, la spec serait totalement fragilisée au moindre changement d'UI ou autres détails d'implémentation.
Je teste évidemment mes composants UI (React, Angular etc), et EVIDEMMENT que je le fais en TDD.
Cependant je le fais bien après avoir codé le "Core Logic"; car c'est lui la pierre angulaire du projet.
Ces tests de composants UI sont unitaires (pas de Selenium, pas d'http calls etc.) mais en revanche TRAVERSENT BIEN mon core logic, je ne mock/stub rien de celui-ci !
Ca devient en quelques sortes des tests end-to-end (car traversant deux mondes : UI + Core Logic), mais bien unitaires.
Ils testent principalement la délégation à mon Core Logic et son dénouement UI conceptuel, y compris celui-ci.
Mais attention, je ne teste pas TOUTES les règles de gestion du Core Logic mais juste une toute petite poignée; généralement un happy path et un wrong path; car le but est bien de s'assurer de la collaboration entre les composants UI (React, Angular), et mon Core Logic; ce dernier étant déjà full testé.
Life cycle's components, Redux selectors implicitly called by the UI, Conditional templating etc., tout y passe.
Avec Redux par exemple, un test UI consiste à vérifier si après call de mon core logic, mon selector orienté "vue", mon View Model donc, est bien opérationnel et fait ce que j'attends.
En revanche je ne touche pas à l'UI pur (html, page object etc), mais démarre directement auprès des composants React ou Angular ou autre.
TOUT EST EN TDD, JAMAIS DE TEST-LAST ATTITUDE.
@@wealcome_company Merci beaucoup pour ta réponse rapide ! Pour conclure, est-ce que tu as déjà vu en œuvre ou implémenté le Journey Pattern (ou ScreenPlay pattern comme il s'appelle maintenant) ? L'idée étant juste d'avoir une abstraction des actions utilisateurs, qui permet ensuite de lancer les tests en injectant les dépendances nécessaires : la core logic uniquement, les services pour tester la couche contrôleur, voire injecter une implementation qui touche vraiment l'UI.
@@Yoy077 Ce que j'ai décrit au-dessus est déjà en un certain sens une abstraction des actions utilisateurs; en effet je stresse directement un composant UI ou encore jette une action Redux.
Je descends juste d'un cran en fait. HTML (Cran X+1) ----> Components (Cran X).
Pas besoin de pattern d'abstraction pur UI, ou encore de Journey Pattern.
Toutes les dépendances nécessaires à un test en particulier (généralement InMemory donc, car comportement UNITAIRE), sont injectées par celui-ci.
Je ne teste jamais à partir des pages/balises HTML, ces dernières étant beaucoup trop sujettes à la modification, donc ByBy selenium et compagnie, leur intérêt frôlant le néant et leur maintenance étant nauséabonde.
@@wealcome_company Ok merci ! Ça rejoint en effet ce que je pense aussi ! Je m'interrogeais simplement car on voit beaucoup du UI-first driven development apparaître ces dernières années, notamment avec GraphQL. Mais selon moi ces méthodologies disent la même chose : ce qu'ils appellent UI-driven est en fait use-case driven, donc au final ça revient au même ! Par ailleurs (sans rapport direct avec la phrase précédente), je ne doute pas que tu aies déjà jeté un œil à ça mais si ce n'est pas le cas tu devrais vraiment aller voir tout ce qui tourne autour de l'Event Storming !
@@Yoy077 Le Use Case-driven c'est pointer le Core Logic directement et uniquement lui; car c'est là où se trouvent les use cases. Sinon c'est du UI-Driven à mon sens.
Oui je connais l'Event Storming :)
Très bonne vidéo, comme d'habitude ! Petite question tout de même : quelle est vraiment la différence entre BDD et ATDD car souvent les 2 acronymes sont utilisés indifféremment?
Franck LAMY BDD c’est l’art de trouver et d’élaborer des exemples par conversations.
ATDD c’est tout le côté exécutable des scénarios, tout le côté « development guided by scenarios ».
ATDD = double-loop acceptance testing + TDD
OK. Merci pour la réponse. Donc si je comprends bien, pour simplifier et résumer, BDD = Gherkin et ATDD = mise en oeuvre avec Cucumber.
Franck LAMY BDD = conversation (discussions)
ATDD = Gherkin + interface avec le code
Que veut dire core logic ?
la logique du "coeur" => logique métier, cerveau de l'application
Comment mettre en place ce projet sous Eclipse. Merci de fournir le document technique, stp.
C'est moi ou il y a un mec relou devant qui n'arrête pas de parler en même temps ?
Je viens juste de comprendre pourquoi personne n’utilise ce truc
Quelle est donc la raison selon toi ?
Ce mec n’a jamais fait de dev ! ca se voit
Pourquoi dis-tu ça ?
Nulllll germain nulllllll
pourquoi ?