Aller au contenu
Tous les transcripts
Podcast / conversationMontréal JUG· 9 février 2024 27 minDivertissementNumérique

Comment générer des stubs wiremock avec openapi generator par Alexis Couvreur

Transcription youtube_captions. À recouper avec la source d'origine.

Analyse automatique

Générée par IA — peut contenir des erreurs. Méthodologie

Chapitres

Répartition du ton (temps de parole politique)

Propositif 100 %

Questions et réponses

Taux de réponse directe : 100 % (directe = 1, partielle = 0,5, éludée = 0)

  • 21:03OuverteRéponse directe

    Est-ce que c'est bien de faire ça quand on n'a pas le vrai service derrière ?

  • 21:42RelanceRéponse directe

    Est-ce que ça cache des problèmes comme la latence ou le monitoring ?

  • 22:25RelanceRéponse directe

    Est-ce que ça remplace des tests plus poussés ?

  • 23:06OuverteRéponse directe

    Pourquoi c'est mal nommé 'mocks' ?

  • 23:50RelanceRéponse directe

    Est-ce que ça remplace des tests d'intégration ?

  • 24:35OuverteRéponse directe

    Est-ce que ça gère la gestion de version des contrats ?

Temps de parole

  • Alexis Couvreur100 %

≈ 0 interruption / 10 min (chevauchements et interjections détectés).

Modèle mistral-small-latest · prompt v1 · les citations sont vérifiées mot pour mot dans le transcript ; le taux de réponse directe est calculé à partir des verdicts question par question. Aucun label idéologique n'est produit.

0:10
Alexis Couvreur

ok euh je vais commencer pour la présentation donc bonjour à tous merci d'être venu ici pour pour une présentation du jug je vais vous présenter quelque chose d'assez particulier on va parler de openia generator on va parler de wirem donc tout ça autour de Java et je vais me présenter d'abord donc moi je suis Alex couvreur je travaille à la Banque Nationale du Canada en tant que ingénieur logiciel et puis j'aime beaucoup travailler avec du code où je essaie de faire de la qualité j'essaie de faire des choses qui sont pas redondantes typiquement ce qu'un dev normal aimerait faire et donc aujourd'hui c'est pour ça que je vous présenter quelques sujets d'abord on va voir ce que c'est wirem voir ce que c'est open API voir ce que c'est open API generator et on va voir comment est-ce qu'on écrit un test d'intégration selon moi je vais faire une première démo de Mo b on va voir à quel point des fois créer un écrire un MOOC ça peut être contreintuitif ou ça peut nous donner une fausse impression de d'avoir correctement écr un test je vais vous montrer ce que c'est que Java Wiem et la démo partie 2 donc tout d'abord wirem c'est un outil c'est une librairie qui vous permet d'écrire des MOOC pour des API donc vous avez une API typiquement distante vous avez pas forcément envie de l'appeler durant votre cycle de développement donc vous pouvez vous créer avec ça un environnement stable local isolé que vous pouvez reproduire avec des expectations qui sont justement définis la partie de wirem parce que ça c'est large ils ont beaucoup de clients pour du Java pour en tant que serveur déployé sur le Cloud ils ont plein de choses la partie que je vais aborder ce soir c'est principalement ce genre de d'utilisation dans un test qu'on va écrire Java on va spécifier un stub on va écrire des des attentes des expectations à propos d'un serveur qui existe et on va pouvoir faire des appels dessus et il va nous répondre si on lui parle correctement comment est comme est-ce qu'il attend deuxème sujet open API est-ce qu'il y a des gens qui connaissent open API dans la salle levez la le bras si vous connaissez ok je vais quand même décrire un petit peu ce que c'est mais rapidement c'est un standard en fait qui permet décrire les communications HTTP ça permet à plein de gens en fait de se passer ce document et de savoir comment interagir ensemble à partir de ça on peut aussi générer beaucoup de clients beaucoup de serveurs même beaucoup de beaucoup de documentation il y a pas mal de choses qu'on peut qu'on peut faire autour de ça c'est assez génial et une spec ça ressemble à ça rapidement je sais pas si on voit mon curseur mais ouais rapidement il y a pour chaque endpoint qu'on va définir on va définir un on va définir une méthode HTP on va définir le nom de l'opération on peut expliquer le le request body qui est défini les réponses possibles et cetera donc plus c'est enrichi mieux on communique avec les clients les consommateurs les attentes de notre app le comportement qui peut y avoir et maintenant je vais présenter openia générator rapidement qui est-ce qui connaît open générator lever la main aussi qu'est-ce qu'il utilise maintenant lever la main donc openp gérator c'est notamment un outil qui est dérivé des avantage de open API c'est qu'on peut justement générer bah du code à partir d'une d'une spécification ce ce projet là qui est un projet open source sur GitHub écrit en Java il permet en fait de lire et parcer ces spécifications et de traverser tout l'arbre et pouvoir générer tout ce qu'on veut à partir de donc eux ils appellent ça bah typiquement un fichier mustache qui est en fait un des templates de de fichiers qu'on va venir dedans y intégrer ben toutes les références à une spécification donc typiquement operation c'est toutes les opérations qu'on va avoir dans notre contrat on va pouvoir y tirer dessus donc ce qu'il fait c'est ça he c'est qu'il prend une spec en entrée il prend un template il mélange les deux il applique la le parcing de la structure et il peut générer tout ce qu'on veut donc typiquement en SDK écrire un test d'intégration on va s'intér s'intéresser donc à cette partie-là de la pyramide et là je vais avoir besoin un petit peu de vos vos vos feedback euh moi personnellement quand j'ai cré un test d'intégration dans ce contexte où mon application doit se faire consommer par quelqu'un et qu'elle celle-ci elle doit parler avec une autre API donc il y a vraiment nous le middleman au milieu on on s'intègre en fait avec une API et on on a des on a des attentes donc typiquement on a une requête qui arri on fait un col à la p externe et on renvoie la réponse basique simple c'est ça va être notre notre contexte ici donc personnellement quand je quand je communique avec une API externe je génère un client ça peut être aussi un client qui a été écré à la main parce qu'on av pas envie de le générer peut y avir plein plein de raisons en tout cas c'est des petits modules comme ça qui apparaissent au milieu et donc dans un test on va toujours voir la même structure given when then on va vraiment avoir les attentes en fonction de l'entrée le comportement qu'on va y intégrer dedans et les attentes au niveau du de la réponse donc le given le den mais le làdedans c'est là où souvent y a différentes écoles où est-ce qu'on va le mettre est-ce que le when ça revient au final à mettre un comportement au niveau du client donc on va le moquer ou est-ce que c'est au niveau des appis externe est-ce que ce qui ceux qui pensent que on va mettre au niveau du l'AP client lever la main et ceux qui pensent qu'on va le mettre au niveau de la pay externe lever la main ok intéressant de voir ça donc personnellement il y a toujours des choix différents mais je le mettrai au niveau de la paye externe je le mettrai au niveau de la paye externe parce que ça permet vraiment d'avoir savoir exactement ce que la paye externe s'attend à ce que nous on lui on à comment est-ce qu'on communique avec elle et comment est-ce est-ce que elle va nous répondre en fait si on moque le client on risque d'avoir un peu plus de un peu plus de mal à bah justement on va on va tester les les internals en fait du client on va on va essayer de générer des cas d'erreur mais il va falloir un peu taper sur le client pour qu' pour qu'il nous répondre d'une certaine manière première démo the mokes back euh on va voir un petit truc rapidement c'est une application en CLI qui qui envoie des mails à travers une API donc c'est classique hein on a quelques arguments d'entrée et elle envoie des mails c'est simple elle en elle envoie ça à un recipient avec un un body message et le truc ici c'est que l'API de mail qu'on va consommer c'est voilà c'est c'est notre c'est une autre équipe à côté la seule chose qu' nous ont donné c'est une spécification openi donc la seule chose qu'on a c'est ça ils nous ont pas donné de client s n'importe quoi on a rien du tout on a juste la spécification démo je vais essayer est-ce que tout le monde voit bien l'écran je sais que c'est pas peut-être pas très très simple ok dites-moi si vous voyez pas je peux zoomer donc on va commencer dans le dans le main entre guillemets c'est très très facile on a un web client ça c'est un client spring qui qui propose pour juste faire des appels de manière générale à tout le monde dessus on va créer un un un mail client àamano vous allez comprendre pourquoi et ce client il en fait tout simplement ce qu'il fait c'est qu'il est capable de consommer un client pour faire des appels générique en le spécifiant justement comment est-ce qu'on appelle notre AP mail donc je vais rapidement passer sur l'aspec open API mais c'est ça concrètement on a un endpoint de mail là donc là on est un développeur on lit ça on voit qu'ok il y a un request body il attend un schéma avec un new mail il y a un recipient un body et lorsqu'il nous répond quand ça fonctionne bien il nous répond un mail et on voit qu'il peut y avoir un statut un recipient et un body relativement simple et donc nous notre équipe ah ben c'est dit qu'on allait créer le client à la main donc on a fait le client à la main ici on a fait notre client on va faire une request post sur l'URI de base on va envoyer sur mail on va bien faire attention au à l'accept header au content type et cetera on désérialise le le mail ici euh là-dedans donc relativement simple et notre appli tout ce qu'elle fait c'est qu'elle elle va recevoir le résultat et elle veut le print dans la dans la console donc là on suppose maintenant que notre justement notre l'API de mail elle existe pas encore en fait elle existe pas encore et on veut juste s'assurer que nous on appelle correctement cet API donc si on avait moqué le client on aurait pu moquer web client on aurait pu moquer make client API ici mais en fait c'est plus de l'ORD des test unitaires ça parce qu'on va juste vérifier comment est-ce qu'on appelle notre propre client en test d'intégration on veut voir s'il y avait effectivement un serveur là c'est nous qui avons le contrôle dessus mais comment est-ce que notre appis se comporte donc j'ai déjà écrit ce test derrière et on va avoir quelque chose de simple donc ici j'utilise WEM Wiem le truc que ça va faire c'est que ça va nous lancer un serveur sur lequel on va pouvoir mettre des expectations comme je vous ai présenté tout à l'heure et ici nous l'injecte ici donc à chaque test on va avoir un serveur on peut avoir le le base URL et sur chaque test on peut utiliser cette méthode globale qui injecte dans le contexte actuel un stub justement donc on va dire que on veut appeler on veut appeler ici nous la p en question avec le paylo suivant jugexample.org et hello jug donc ça revient à appeler notre notre notre application avec les arguments suivants donc le premier argument que j'ai peut-être passé assez rapidement mais ici qui est là c'est l'URL du Client en question et les les les deux arguments suivants c'est le le recipient et le body donc on va créer le payload qui est ce qu'on attend que notre application produise lorsqu'elle va communiquer avec la p externe et on va avoir la réponse qui est- ce qu'on attend de de laapi qui nous répond on peut un peu modifier comme on veut mais là on va dire que c'est notre cas d'usage donc là je vais écrire ça je vais écrire mon stub à la main post ur path equal to on vérifie que bien on a mails on vérifie qu'on a bien le content type le accept que le request body c'est bien le même donc pour qu'on s'assure que tout que tout soit bien envoyé et le le expectation c'est le le systemme.

out printn de notre application qui va tout simplement print en fait le la la classe en fait en fait qu'on a récupéré donc là je vais l'exécuter euh je vais juste compiler avant pour être sûr que tout est bon mais normalement ça va passer tranquillement donc là on j'ai déjà préparé ça ça c'est le code qui qui était déjà là ok ça marche c'està dire que là lorsqu'on appelle correctement notre API elle fait bien un appel au serveur externe et ça fonctionne et là du temps passe beaucoup beaucoup de temps passe et euh le projet c'est un voilà c'est un stagiaire on lui a redonné ça on lui dit ben écoute il nous envoyé une nouvelle version du de la open API il faut que tu il faut que tu la prennes donc je vais passer juste après pour voir ce qui se passe hop concrètement le changement qu'on a eu c'est que la nouvelle spec je sais pas si je peux rapidement voir l'historique euh hop concrètement ce qu'on va voir c'est qu'ici on a rajouté deux choses le le le client nous a envoyé la la le nouveau contrat et il a ajouté un security schems avant son App était pas sécurisé il y avait rien tout le monde P envoyer des mail c'est pas bien il est pas content donc il nous a dit maintenant vous il me faut un un be token un JWT et je veux la sécurité donc là ce qu'on moi ce que je si siil y a un testintégration qui suit euh tout ça je m'attends euh en avec tout ça je m'attends à ce que euh le le test ne passe plus suivant l'aspec mais pour le moment on génère rien donc on se dit bon le le stagiaire il sait il sait il sait que ça ça passe là il va aller générer un lui un client plutôt donc il va enlever le client à la mano et il va utiliser un autre celuilà c'est le nouveau client généré avec les spécifications de sécurité donc là le test passe moi je voudrais qu'il passe pas parce qu'on a des attentes maintenant dans le contrat qui sont l'authentification le stagiaire il est pas trop au courant de ça ok il voit pas trop qu' faut qu' faut qu'il faut tout ça mais quand même bon j'utilise maintenant mon nouveau client et le test bon il il passe toujours mais c'est là où c'est pas bien c'est que là le stagiaire on va dire qu'il est pas très très malin et il remarque en fait lui tout ce qu'il voit c'est que les tests sont verts les tests sont verts ça passe sauf que maintenant il déploie en prod parce qu'il y a pas de Q il y a rien du tout il déploie en prod et ça marche plus les tests quand ils envoient quand il envoie tout ça il a des des 4 ok bizarre donc là on va faire un autre truc c'est qu'on va juste justement utiliser le on va justement pas utiliser quoi que ce soit je vais continuer la démo la présentation c'est là où on se dit c'est là où moi j'interviens où j'ai vu ce ce genre de chos j'ai vu justement qu'on avait besoin excusez-moi qu'on avait besoin de allez ah c'est non c'est pas passé encore hop j'ai vu qu'on avait besoin justement de générer ça parce que moi j'ai pas envie de maintenir mon mock en fait et donc Java wi Mo qu'est-ce que c'est c'est un c'est un module de open Apia gérator qui va donc générer des opérations et des stubs pour chacune de vos opérations et status code avec les expectations basé sur les cor param les pass parameters tout ça c'est aussi des response sample pour chacune des opérations et des request body d'exemple pour chacune des opérations les deux derniers points on va pas les voir lors de la démo mais c'est aussi des choses qui sont intéressantes à utiliser alors pourquoi bah ça va typiquement montrer ce que enfin montrer ce que je voulais dire les les tests là moi je voulais pas qu'il passe moi je voulais que ça casse parce que justement le le comportement du serveur c'est plus de ne pas c'est plus de de d'accepter des de justement des requêtes anonymes donc c'est typiquement la miss implementation on peut penser juste on s'est trompé de Status code alors des fois ça peut être duit picking mais typiquement un 200 au lieu d'un 200 mais plus on a ce genre de mauvaise implémentation dans les stups qu'on écrit à la main plus on a en fait un stop serveur qui lui-même commence avoir sa vie à part entière c'est out of date aussi ça ça peut être typiquement le contrat le stub on le maintient pas à jour donc il est basé sur sur des anciennes des anciennes spécifications donc on va plus avoir vraiment ce qu'on veut et des fois il y a aussi trop d'endps donc typiquement faire des stub là c'était facile quand je voulais montrer écrit mais quand on a peut-être 30 end points dans un cont contrat on va pas écrire 30 stub sachant que là j'ai écrit seulement un stub pour un status code mais il peut y en avoir qure par par par endpoint et on va pas forcément écrire à chaque fois les qu alors quand est-ce qu'on utilise ça je vous ai déjà présenté un ctisation c'est quand on écrit un cas de test mais on peut générer aussi des stubs justement automatiquement quand on veut distribuer un SDK pour un un client SDK typiquement notre SDK on l'envoie à des gens pour qu'ils l'utilisent mais on veut qu'ils soit en mesure eux de de bah de de tester l'intégration au-delà du client justement et donc on leur propose aussi de stubber les les serveurs qu'on qu'on qu'on met à disposition et aussi enlever du B code donc ça ça va être répété tous les les Stu en en masse alors comment ça marche et là c'est ce que je vais montrer juste après dans la dans la seconde et dernière démo c'est que on va utiliser donc bah moi j'utilise en tout cas comme ça mais on peut générer à travers une image docker à travers de la commande et cetera mais dans mon Maven je mets une exécution supplémentaire où je génère un moxerveur et je vais générer grâce à ça je mets en input laaspec et laaspec va se transformer avec Open générateur en une une grosse classe de stub qui va ressembler à ça donc là c'est intéressant parce que on va voir que on a dedans plein de méthodes qui permettent automatiquement de récupérer des stubs qui sont prédéfinis avec tous les paramètres qui sont qui sont inclus dedans donc là on peut voir le fameux stub post mail de tout à l'heure mais on va voir aussi le stub post mail 400 qui a autogénéré le 401 et cetera et cetera et typiquement ça ressemble à ça lorsqu'on essaie de l'utiliser il y a un truc en plus qui est vraiment puissant que que j'ai mis dedans c'est le ST post mail fault parce que beaucoup de gens dans leur web cent ils font des TR catch sur des web client response exception mais ça peut très bien arriver que ça arrive dans des request exceptions aussi et donc la fault ici qui est une quelque chose que wirem propose ça permet de simuler une faute typiquement le DNS marche pas le le y le il y a une erreur de certificat SSL donc on peut pas envoyer donc il y a une vraie faute à la requête et finalement a new hope je vais vous montrer le qu'est-ce qui se passe une fois qu'on a généré donc là je vais passer à la partie suivante tac c'est pas dans le bon ordre je sais mais je je l'ai fait pour moi quoi donc ce qui se passe ici c'est que dans le test on n pas changé l'implémentation rien du tout dans le test au utiler le gros St que j'avais avant maintenant j'utilise mon St de default API Server ça c'est quelque chose qui est généré ici dans mon package que j'ai généré est-ce que c'est bon maintenant super donc bon ça change pas grand chose j'ai pas trop bien pas trop pas trop fait pas trop raconé truc mais donc ici j'utilise mon default API m Server qui est un une quelque chose qui est généré ici et donc là on peut voir effectivement tout ce qui a été généré suite à Ben le le process làdedans donc on peut voir rapidement en bas tout pas mal d'autres choses c'est aussi des response sample qui sont autogénérés à partir des exemples donc ça peut être assez utile recipient recipient exemple org si jamais ça dépend pas vraiment de vos input vous pouvez aussi avoir des je de données un petit peu comme ça donc là il y a aussi des des respon SLE pour des des erreurs et donc j'uise juste ici et là ce qui va se passer ça va être plutôt intéressant normalement c'est que le test il va fa une petite seconde je recompile parce que il faut que je le génère du coup le test il va fail yes donc le test il va fail parce que ici il va me dire qu'il manque un header authorisation et ça je l'ai pas codé c'est juste que lui le générateur il sait que notre API maintenant comme on a mis une sécurité sur l'ensemble des endp il sait que on doit fournir un auorization header il y FA fa lui il vérifie que l'appel que tu fais avant que passer sur la course de ton Stu il va vérifier que tu remplis au moins des éléments de ton contrat et pu mais ça c'est cloud mais MOOC Server le fait pas ah oui m Server ouais m Server probablement ouis Raj un filter sur la spécification là ce que j'aimais bien avec ça c'est que c'était aussi entre guillemets Compal time tu vois c'està dire ton ton truc là ton ton MOOC ton default mock serveur tu peux le le le le partager c'est une classe c'est assez assez intéressant pour les exemp ouais pour les exemples et pour les ST aussi ça Mo j'ai pas t container tu peux en tout cas je vais essayer de finir rapidement qui passe c'est fait simplement oublié de d'injecter le token donc je pareil je vais reprendre le le changement que j'ai déjà préparé moi ce que jeis utiliser c'est je rajoute dedans un filtre en fait ou dedans je mets un token qui est donné en common Line et et c'est tout et là c'est super important parce que c'est pas notre API elle-même qui change notre API sont quand elle veut elle transférer de la donnée elle le fait là c'est tout ce qui transite autour et c'est pour ça que j'insiste beaucoup sur les testes d'intégration à quel point ils sont puissants c'est qu'ils vont pouvoir tester euh le filtre même de du du de la configuration du web client lui-même donc là c'est vraiment les internals internals quoi et c'est super intéressant parce que ici maintenant si je je crois que j'ai pas besoin de recompiler parce que j'ai juste pas changé le contrat maintenant si je passe mon test il y est parce que j'ai réussi à correctement injecter mon mon mon token alors j'ai modifié rapidement mon test aussi pour mettre le token en dernier argument mais c'est voà c'est tout normalement j'ai plus rien merci beaucoup est-ce que vous avez des questions ouis allô allô ouais super merci beaucoup c'était vraiment cool la démo je suis vraiment d'accord avec la première partie où tu dis que typiquement c'est bien de faire ça quand on n pas le vrai service derrière imagine c'est une autre équipe qui développe le service il est pas encore là c'est c'est cool je suis je pense alors je sais pas si c'est une question mais en tout cas je veux ouvrir la discussion je pense je suis un peu moins d'accord avec la deuxième partie parce qu'en fait ça cache beaucoup de choses comme euh déjà il faut que le serveur a mis à jour son open son open API que tu l' et je suis presque c'est un peu sadique mais je suis presque content que tu es oublié de recompiler parce qu'au final ton test il passe donc déjà il faut repenser à bien recompiler ça ça le fait automatiquement normalement ça le fait automatiquement mais si la la mise à jour a pas été faite dans Open open API toi tu vas penser que ton ton test est bon et et je trouve que ça cache aussi le fait que un test d'intégration c'est aussi pour valider le monitoring l'utilisation du CPU la latence et cetera et du coup si tu moques ça tu perds tout tu perds tout ça peut-être que ça fonctionne mais en fait maintenant tu as un délai de 2 secondes sur sur ton co donc bah encore une fois tu vois je pense que là ça ça se joue dans Qu'est-ce qu'on considère comme étant un test d'intégration ouais mais effectivement ouais effectivement c'est super intéressant ce que tu dis donc il y a des manières de tu sais de mettre de la latence mais je pense que ça va trop loin quoiou ouais et et excuse-moi d mais en plus j'aime bien le fait que tu es testé aussi le les les la failure du côté du client tu parler des DNS et cetera mais il y a plein d'autres cas de failure typiquement je sais pas WS down tu tapes un bad gateaway il est pas dans ton contrat d' API tu peux pas tester du coup tu sais pas trop comment ton application c'est c'est ça c'est toujours un peu le la discussion avec les MOOC mais je suis un peuubitatif c'est ça en fait le le but vraiment de ce générateur c'est de proposer rapidement des mooces auquel tuas tu peux avoir besoin et tu as juste un truc à récupérer c'est le mock et normalement il espère que tu vois ton expectation c'est la même que ce que le contrat défini parce que c'est au moins pour éviter tu vois toi de maintenir à MOOC ouais ouais ça je suis d'accord pas tributaire et en plus l'implémentation elleemême mais je trouve que ça donne une confidence supérieure à ok ça fonctionne mais je suis pas certain je suis pas certain que ça suffise pour se dire ok pyramide il y a quand même des tests encore auudessus ouais ouais ok ti ouais euh moi ma question c'est premièrement bon je trouve c'est mal nommé ces chosesl par c'est plutôt des stubs qu' sont fait que des moocs ouais ça le client et le stub c'est que tu as vraiment simulé le comportement de du système mais là tu parles pas du problème moi ce que j'aime bien dans cette approche là c'est la baisse du coûp du test pas besoin de déployer je fais sur mon poste et Cera la baisse du coou il suffit d'un bug il suffit d'un bug en T c non non mais après j'aurais éventuellement un test qui va rouler automatiquement ou monitoring ou si je fais du Canar par exle ça remplace pas des test plus poussé où tu as pas de St derrière ouais mais en fait après on ça s'appelle intégration moi c'est pas un test d'intégration parce que tu testes pas avec ou le but c'est quand même que ce soit un moment où tu peux pas tester avec un serveur qui est déployé par exemple tu vois c'est vraiment ça mais si tu arrives dans ce cas je pense que tu as un autre problème vraiment tu dis peux pas leestème approche s'ppelle s'appelle testing donc ils sortent de la pyramide des tests que tu vois actuellement ils appellent ça on comm et ce qu'ils appellent des tests unitaires intégrés et en fait c'est qu's sont totalement en isolation il dépend de personne derrière parce que le problème c'est que si tu prends un service extérieur il faut que tu contrôles complètement ton jeu de données ça ça coûte hyper cher à contrôler je suis d'accord par contre que tu as dit ce que tu dis pas là c'est qu'en fait tu as changé ton contrat et en fait dans l'histoire que tu montres là c'est que tu as pas de gestion de versing donc en fait faut tu es attaché tu dis mon développeur il a non non le contrraire il a changé de l'autre côté donc donc il faut que que tu es une gestion de toi tu te trouves dans ton microservice à devoir gérer la version des contrats de chacun des contrats quees de tes fournisseur et donc là le gars il a il a il a pas cassé son contrat le gars c'est toi qui a cassé le contrat de l'autre côté donc tu as une version 2 puis moi je suis je suis sur la version 1 puis le jour où je donc si ça si ça met plus à marcher en production c'est qu' a quelqu'un qui m'a cassé le contrat de l'autre côté donc il est censé maintenir son contrat le temps qu'il a des clients patati patata et cetera donc pour ça que ça ça aussi la gestion des contrats c'est sûr que oui les les les les exemples que j'ai utilisé sont quand même très extrapolés mais tu peux justeêtre en préparation une intégration avec une nouvelle version ouais non ce qui est bien c'est les exemples par contre c'est de simuler de pas que moi je suis une équipe je récupère tes contrats qui sont déjà faits et je me tape pas à me taper toute la gestion de des des faux payloodes qui potentiellement pour être faux en fait voilà par exemple un formatage Jason c'est j'ai j'ai une date et toi tu as décidé que la date c'était jour mois anné ou un timeestamp n'importe quoi puis moi je me trompe je fais une erreur puis en fait mon retour il est totalement faux je code quelque chose qui antement faux quand je reçois vra le vrai col en fait ma date était pas formatée comme il faut c'est pas la bonne time zone c'est pas plein de petits problèmes comme ça quoi est-ce qu'il y a d'autres questions c'est pour pas embêter les gens mais s'il y a d'autres questions je veux pas non plus les bon on applaudit