 Bonsoir Montréal-Piton, good evening Montréal-Piton, and welcome to Montreal-Piton 87 Italic Replay. Bienvenue à Montréal-Piton 87, rediffusion italique. J'ai quelques petites annonces pour vous et puis on va passer à notre contenu principal très bientôt. Donc première chose, joignez-vous à nous sur Slack. Vous avez l'URL ici, mtlpip.org.fr slash slack in et on est dans le canal meeting. Et puis je vais enlever la petite bannière déroulante ici, boom, c'est fait. Autre chose, on a un code de conduite à Montréal-Piton. Donc le code de conduite c'est facile, ça dit que tout le monde devrait être excellent les uns envers les autres. Si vous voyez quelque chose que ça ne vous semble pas être excellent, trouvez-moi sur Slack ou duk, moi je suis Yannick et duk, c'est duk sur Slack. Et dites-nous là et puis on va se faire de notre mieux pour régler cette chose-là qui ne vous semble pas excellent. Donc première chose, joignez-vous à nous sur Slack, le URL est là-bas, nous sommes dans le canal meeting et nous avons un code de conduite à Montréal-Piton, qui dit que nous devons tous être excellentes entre l'un et l'autre. Si vous voyez quelque chose qui ne vous semble pas excellent, trouvez-moi sur Slack, je suis Yannick, ou duk, c'est duk sur Slack. Et dites-nous et nous allons faire de notre mieux pour résolver quelque chose qui ne semble pas excellent. Donc notre programme pour aujourd'hui est de me dire un couple de choses. Et puis nous allons avoir une présentation en anglais avec Diana Rodriguez, qui est un tech pour le bonheur. Je ne sais pas ce que c'est, mais on va le savoir très vite. Et puis Sébastien Port-Port-Bois va nous parler en français sur le test de propriétés. Et puis nous allons avoir, comme usual, une heure virtuelle sur Jitsi. Je pense qu'il y a quelque chose à dire. Je ne sais pas ce qu'il y a. D'autres choses que je devais mentionner sont que, en juillet 6, donc la semaine prochaine, la semaine suivante, nous allons avoir une autre soirée de programme et de pratique. Cette fois, il va être sur le data analysis avec Pandas. Donc si vous n'avez pas attendu les dernières programmes de pratique, c'est que nous avons juste un défi, on a ouvert un live stream sur Jitsi, et nous collons ensemble, on a des exercices, on a des questions, on a des choses à essayer ensemble. C'est une très bonne chose. Nous allons avoir une autre soirée d'exercice, le 7 juillet, pardon. Cette fois-ci, ça va être orienté sur l'analyse de données avec Pandas. Et si vous n'avez jamais assisté à nos soirées d'exercice, on fait juste tout le monde arriver sur Slack et on fait des exercices ensemble sur Jitsi en utilisant Google Collab. C'est un Jupyter Notebook hosté par Google. On peut faire de l'édition de code en concurrence fantastique si vous n'avez pas beaucoup d'expérience en analyse de données. Je vous recommande fortement cette soirée-là. Et ensuite, on va prendre une pause pour l'été et puis on vous revient en septembre avec Montréal-Piton-88, qui va avoir un nom aussi loufant que Montréal-Piton-87, mais qu'on n'a pas encore trouvé notre nom loufant. Donc suivez-nous sur nos réseaux sociaux comme d'habitude, ou sur Meetup et puis vous allez recevoir l'annonce pour Montréal-Piton-88. Et un gros merci à notre partenaire FGNR, vos consultants favoris pour tous vos besoins en Piton, à Montréal, en particulier pour le développement de Django et qui, gracieusement, héberge notre serveur JITSI pour la vidéo-conférence de notre 5 assets virtuels ce soir. Merci beaucoup à notre partenaire FGNR pour tous vos besoins en Montréal, surtout Django. Et ils hostent le livestream qu'on va avoir pour notre virtual happy hour aujourd'hui. Et c'est tout que j'ai besoin pour les annonces. Et je vais l'introduire Diana Rodriguez qui a été une devops et un développeur pour 20 ans. Elle s'adresse de North Carolina aujourd'hui. Et elle va nous parler de tech pour... je l'ai oublié. Mais elle va nous parler tout. Diana, le stream est pour toi. Merci. Bonjour. Je suis Diana et je ne me rappelle pas de toutes les choses que j'appris en français. Désolé parce que je ne vais pas le français mais ma français c'est terrible. Mon accent c'est terrible parce que j'étudiais deux ans tout le monde. J'ai suivi la Venezuela et c'est pour ça que je parle espagnol. Et je pense que c'est plus facile pour nous que parler en espagnol pas le français mais j'ai oublié de presque tout. C'est pourquoi je dis je suis désolé pour mon français mais oui je vais parler de technologie tout compte Python IoT et connectivité et c'est un différent un différent type de parler parce que ce n'est pas un super tech dive je pense que la plus importante partie est l'attention pour comment nous pouvons avoir un impact positif dans la vie de beaucoup de gens donc d'abord je vais m'introduire moi-même comme je l'ai dit je suis Diana Rodri et je suis un avocat d'advocat à Twitch j'ai été en faisant Python et en faisant des choses pour les derniers 20 ans donc vous pouvez me trouver sur Twitter c'est Kutufai82 et le titre de mon talk est Everything Counts et c'est une de mes favorites c'est une de mes favorites mais on va faire un contexte je vais parler de Python mais je vais aussi parler de diabetes en 2019 j'ai été diagnosé avec type 1 de diabetes et je me sentais exactement comme ce que vous voyez dans la photo d'eux d'eux les personnages que vous voyez dans la photo je me sentais comme ça et je je ne savais pas ce qu'il faut faire et je me sentais qu'il n'y avait pas très peu que je savais de diabetes même maintenant que j'avais donc on va vite voir ce que la diabetes est et puis on verra comment cela intervient à Python donc type 1 de diabetes est quand votre corps ne peut produire des insulins type 2 de diabetes est quand votre corps produise des insulins mais ne sait pas ce qu'il faut faire et vous êtes résistant à des insulins il y a plus de types de diabetes comme de diabetes gestational type 3 et d'autres types rares mais en en simple des mots ou en des mots c'est un disease qui affecte beaucoup de pays incluant les États-Unis et Canada et il y a très peu que les gens connaissent l'un des parts les plus importants c'est comment c'est d'avoir de diabetes surtout dans les États-Unis ces prix que vous voyez sont de 2016 donc c'est bien c'est presque 6 ans vous voulez savoir combien je spending par mois si je n'ai pas d'insurance dans les États-Unis mes supply et mes insulins me laura environ $2,500 à $3,000 par mois j'ai d'insurance et j'ai je suppose que mon expédition va descendre $5,000 par mois imagine ceux qui n'ont pas d'accès à les prévénies que j'ai parce que je suis un développeur je peux dire je vais faire bien pour m'aider par ce disease avec d'insurance mais c'est pas seulement un point de coûts et quelque chose dans les États-Unis c'est un monde et la question à part de la cost c'est comment c'est à part de de d'insurance et particulièrement ce que j'ai on fait un process automatique que le corps on on on on on on on on on on on on on pas de le corps on on on on on on on on on on on on on on on on on onodel ouาก nous clarity je en milligrammes par deciliter, mais plus comme millimoles. Mais si tu te donnes une scale random, une scale de lignes avec les valeurs que ton sucre doit être dans, et puis ils disent, « Bien, on va essayer d'adjuster ta dose, et on va aller avec ce qu'il y a de l'insulin, et voir ce qu'il y a de l'insulin ». Dans ce processus de voir ce qu'il y a de l'insulin, tout le monde se sent malade, c'est compliqué. Et c'est compliqué parce que, pour exemple, je me donne trop d'insulin, je peux mourir. Si je ne me donne pas suffisamment d'insulin, je peux mourir. Et puis, ma pensée m'a trouble, et j'ai pensé à cette petite personne qui m'a donné la permission de partager cette photo avec toi aujourd'hui. C'est ma fille de 8 ans. Elle est aussi un type diabetique. Et elle nous montre à quel point elle est graceuse que, avec la technologie, elle peut avoir une meilleure et plus normale vie parce que la technologie est accessible à elle. Et c'est ma main d'inspiration pour la plupart de tout, tout dans la technologie, parce que je me inclure aussi maintenant comme un diabetique et à chaque autre personne, je peux m'aider. Qu'est-ce que je vous donne plus de contexte ? Et qu'est-ce qu'ils ont à faire avec Python ? Right ? Bien, il y a beaucoup de pompes et de sensors dans le marché. Et ils ont un job amusant. Ils ont simplifié le processus d'exemple, des sensors qui ont pris le pain d'avoir à couper mes doigts plusieurs fois par jour. J'ai l'une ici. Et puis, les pompes ont pris le pain d'avoir à couper moi-même plusieurs fois par jour pour donner mes injections, ce qui en fait cause vraiment de l'impact et puis, à un point, parce que le doigt de venir en et en pour tant de fois et dans un long temps de temps, cause-t-il des doigts qui font l'air prone pour ne pas absorber l'insulin comme il devrait. Donc, oui, la technologie a été très utile. Mais vous savez ce que les pompes et les sensors ne parlent pas toujours la même langue et ils ne communiquent pas entre eux-mêmes. Donc, une des choses cool que la technologie a brûlée et c'est pourquoi la tech for good est incroyable. C'est NightScout. C'est un CGM web base. Il montre le temps en réel et il a un model second régressif de second ordre, par exemple, en Python qui peut prédire jusqu'à 30 minutes de niveau de sugar. Donc, le service read d'un database d'AmongoDB qui apporte le data de ce sensor et puis il a aussi des alarms pour les valeurs en haut et en bas et c'est un source libre. Et oui, c'est cool. J'ai mon sensor. Je peux justement checker mon sucre bleu et mon téléphone. Et puis je peux utiliser ce software libre en source libre dashboard qui déplace ceci en ligne. Et puis ça m'aide à faire des meilleures décisions et c'est cool. Mais si vous voulez vraiment regarder, si vous voulez vraiment voir où mes niveaux de sucre bleu sont maintenant, j'ai invité pour connecter à cette particular url et vous verrez quelque chose comme ça. Ce sont mes valeurs de sucre bleu. Vous pouvez aller à dianox.superdi.dev. Et si vous ne voulez pas aller à cette url, vous verrez quelque chose comme ça. Je souhaite que les numéros soient bons, mais bien. Donc, c'est un problème que la technologie a évolué parmi tous ces grands devises. Ces données peuvent être accessibles par les gens qui pensent les gens qui carent mon docteur, ma famille, mes amis. Et il n'y a pas de problèmes privés parce que ces sont juste les numéros. Personne ne peut performer des actions. Personne ne peut faire quelque chose avec ces données. Personne ne peut faire quelque chose avec ces numéros plutôt que savoir si vous êtes plus ou moins. Dans mon cas, les gens qui savent les meilleures parce que ça peut m'aider dans des situations confortables, parfois je ne peux même noter si je ne suis pas dans range. Le deuxième problème qu'on a sorti est l'automation. Oui, nous avons ces sensors et nous avons les pumps. Mais il y a d'autres méthodes pour automater un processus que nous devons utiliser manualement. Et ici, Python s'occupe s'occupe en handi. C'est l'automation artificielle pancrisse. Et c'est un très safe et super puissant et super avance mais très understandable l'automation artificielle pancrisse. Et c'est basically décider pour ajuster l'insulin de l'insulin de l'insulin automatiquement pour maintenir les valeurs de bloc lucratif dans un range acceptable à tout moment. Donc c'est essayer de performer la fonction que les pancrisse ne peuvent pas basé sur différents variables, différents données comme combien de carbohydrates j'ai pris, combien d'insulins j'ai sur-bord. Quand était-ce que j'ai les dernières? Quels sont mes ratios? Qu'est-ce qui est mon facteur de sensibilité? Et si je commence avec ça, je peux contrôler les délivres manually et puis ce système donne mon data et peut me donner meilleures décisions et je peux faire meilleures décisions basées sur ces suggestions. Je peux vous dire pour certain que jusqu'à ce jour pour les dernières 3 ans, chaque suggestion que cela a fait a été posée même quand j'ai suggéré pour arrêter l'insulins de délivre ou quand je devrais ajouter plus de basées et des choses comme ça. Et cela est tout fait en Python. Ce n'est pas merveilleux? Et puis il y a un component IoT qui fait apprécier à quelqu'un qui veut être partage de cela. Et ceci est une autre chose qui s'est passé. Maintenant, en termes de hardware, oui, pas tous ces devices sont accessibles. Ceci est à peu près 700 à 900 dollars par mois. Il y a bien sûr, j'ai l'insulins, je n'ai pas payé que beaucoup, mais quoi pour ceux qui n'ont pas d'insulins? Il y a un autre dévice qui est de la faute et qui est aussi très efficace. Mais il ne sent pas d'automatically chaque 5 minutes comme ça. C'est-ce le freestyle que j'ai livré quand vous devez scanner vous-même? Pour retirer cette complexité, part de ma ou notre contribution est de faire des vices comme ces accessibles, mais oui, il y a des solutions commerciales mais elles sont souvent inaccessibles et très expensives. Et c'est ce qu'un test peut devenir. Mais il y a un projet de call limiter qui a été abandonné dès que la solution de la première solution est arrivée et vous pouvez contribuer à ça. Je suis toujours en train de rappeler un couple de choses. Je teste ça sur ma mère qui est un user qui essaie de faire plus petit et plus efficace. Si vous voulez savoir plus sur ça, c'est maintenant travaillé sur circuit python. Donc je suis heureux d'answer toutes les messages sur Twitter sur Twitter. Maintenant, mon projet personnel s'inclure à développer un moyen pour envoyer ce sensor de data en utilisant un bloc de wisp. Un système IOT modulaire. J'ai un RAC wireless, mais il nous permet de construire des solutions comme des blocs légaux. Et vous pouvez juste ajouter des modules sur le top. C'est de 20 à 25 US dollars. Et ça a été utilisé pour construire un tracker, un tracker qui utilise l'Ora 1 dans cette transmission de data. Avec ça, on ne peut pas seulement transmettre des data de glucose. On peut gérer des armes et en cas d'émergence, on peut partager la location exacte de ceux qui sont en crise. Et c'est ce que je parle de quand il s'agit d'utiliser la technologie pour bien faire un impact positif. On n'a pas l'idée de comment une seule ligne de code peut faire à tant de gens comme moi. Je ne vais pas aller dans les détails de des détails. Je suis tellement excité que je ne peux pas même parler le langage correctement. Mais il y a MicroPython et CircuitPython qui, par contre, ont été développés. Et c'est mon flag, parce que j'ai souffert en développant ce Nc. C'était très difficile de venir de la simplicité de Python et de voir que c'était un coeur et un stp pour moi. À un moment, c'est ce que ça marche. On a des données des sensors et des applications d'open source pour les trackers. Les trackers sont en fait des données par la Laura1. La Laura1 transmet des données sur les endpoints pour le dashboard. Et puis nous pouvons être connectés même si on a des connectivités mobile ou pas. Et vous savez à un moment, le nombre de hotspots pour cette particularité que j'utilise, qui s'appelle Helium, n'est pas large. Vous savez, les problèmes que nous avons dans le monde avec cette factory qui s'étend à l'âge de ne pas avoir assez de chips pour produire des choses. Il y a très peu de hotspots qui sont faits et qui sont poursuivies comme elles peuvent être. Mais l'un des avantages de cette particularité qui s'appelle Helium est que ça vous permet de m'aider c'est-à-dire HNT comme vous avez de la trafic dans votre hotspot. Donc l'idée est de construire une networks en blockchain et crypto et toutes ces choses que je n'ai jamais eu aucune idée mais je peux voir le bénéfice d'utiliser une connectivité d'expandant sur ce qu'on already connaît comme des méthodes traditionnelles. Et ceci est un écran d'un des jours où j'ai pris un tour et et c'était ma location quand j'étais à 133 et j'ai testé ça avec ma mère et c'était c'était incroyable. Mais il y a plus et c'est la action Python Python en action. Flask est l'un de mes préférentes frameworks j'aime ça parce que c'est user-friendly. J'aime les décorateurs où vous pouvez spécifier la route et la méthode et s'organiser votre code dans un moyen que même quelqu'un qui est un très grand personne en Python peut l'aider et figure tout ce que vous faites. Donc ceci est une application Flask qui utilise either Twilio ou Vonage et ça vous donne l'option de envoyer des messages SMS ou des messages WhatsApp en cas d'émergence. Comment ou pourquoi? Bien quand j'ai dormi je n'ai jamais l'alarmée. La seule chose que j'ai ici c'est quand mon téléphone s'arrête. Je pensais bien nous avons un range standard de des valeurs et de la façon dont elles doivent être. Et la plupart ont des phones mobiles. Donc la solution est une application Flask où vous pouvez l'enregistrer et vous pouvez configurer les détails comme votre code ce code d'entrée des endpoints qui agiront les dernières readings et les dernières dans les dernières 60 minutes dans un scheduler un thread python avec un scheduler et puis vous pouvez entrer votre propre numéro si tout est en train de s'arrêter dans mon cas il m'a appelé d'abord et je sais que je vais réveiller si je vois mon téléphone si je ne s'arrête alors il m'a appelé mon contact d'émergence qui dans ce cas est ma maman et si elle ne s'arrête alors je peux ajouter 5 contacts d'émergence si personne ne s'arrête ils vont tous obtenir un message texte avec les détails de mon blog ou un message de WhatsApp comme d'aujourd'hui le Python app est 100% il y a un tutoriel inclus j'ai besoin d'une nouvelle édition d'une communauté qui a ajouté le blog tracker il est encore testé je suis aussi construit un app mobile pour payer le blog configurer tous ces détails j'ai dit plus d'émergence contact plus des messages pour donner la fonctionnalité à ceux qui n'ont pas un tracker comme ça et je suis aussi construit un app pour en savoir comment il y a un app d'une seconde en en en en en en en en en en en en en en en en en ça fonctionne et ça perfume ce qu'il devrait, mais je ne pense pas que j'ai tous les perspectives, tout le monde compte. Nous pouvons tous avoir un impact positif dans la société, nous pouvons utiliser nos technologies superpowers pour bien. Et c'est tout que je voulais vous partager aujourd'hui. Vous pouvez parler de moi, vous pouvez aller à mon site superdai.dev, si pas Kutufai82 sur Twitter, ça signifie Popcorn en spanish, en venezuel en spanish, c'est comme un monde étrange. Il y a un repository pour le projet Alpha Centauri 82 forward slash scout x et aussi le URL pour les slides et je suis so happy to have spoken to you today. Merci so much and well I hope to see you and your contributions on GitHub. Thank you so much Diana. We have time for some questions and I will introduce John, who is going to be our moderator for questions. John, are you here? I see your mic as muted and while John is coming back from whatever he is doing. I remind everyone you can ask your questions on the live stream on YouTube or in Slack, in channel meeting. Oh, here's John and I will let John take it from there. Salut tout le monde. Pour le moment, il n'y a pas encore de questions, j'ai vérifié sur, on n'a pas encore eu des questions pour le moment. On attend un petit peu. Vous avez des questions? I think I see a question in the comments actually. Ok, oh, il y a une question. Do you have a code on the wearable device that will link to your historical data page, will it help to diagnose a problem? I don't have a QR code other than to pair, but I think that's a really good idea. There is a way to have an endpoint that shows historical data and can run reports on both sides, on NightScout or in the other app. I'm sure that rather than helping diagnose a problem, this data can be a good point of comparison. I say every six months I have to see a doctor, diabetic patients have to see doctors to check their A1C's to see what the median of the blood glucose details have been. This could be a good way to estimate that A1C level and to show historical data and I think it's a really good idea to add a QR code for scanning those things, just to run it to the report. I see another question. How many contributors are in the project right now? For the moment it's only been four or five contributors and they have done various things. One person added a deploy to Heroku button, the other person added more possibilities of requesting information and the latest contributor basically added a functionality to add Twilio as well to the equation. So if there's anything you feel like you could contribute with, it would be amazing if you want to chat about it, you know, get as much help as possible because it's only me at the moment running the project but it has actually saved my life. Okay, merci. Merci. I don't have a communication channel for this particular project but I am always in the Rack Wireless Discord server or the Helium Discord server. I'm actually one of the moderators in Helium so I'm usually there. It's like my favorite place to lounge but you can also find me in all the Google Developer groups. I'm also a Python contributing member so I am in the Python Discord server. My name is like the same everywhere Kotufa82 so anytime you want to reach out, you can reach me on social media or on Discord in the Python server or the Helium server. Okay. Thank you. Thank you but l'autre question c'était la même chose. C'est comme like Slack or something else. T'as donné la réponse. Je vais vérifier s'il y a d'autres questions encore. Merci à tout. Je pense que c'est tout. Okay. Super. Thank you so much Diana. Merci John pour ton âge avec les questions and I will introduce our next speaker. So our next speaker is Sébastien Portbois. Sébastien est un architecte chez Ubisoft qui est un petit peu paranoïaque du côté des déploiements puis il va nous parler de ça justement ce soir et puis aussi il y a ce problème là qu'il lit beaucoup trop de livres. C'est un beau problème à avoir. J'espère qu'il va nous en parler un peu comment on pourrait nous aussi avoir un tel problème. Sébastien, je passe la parole. Merci. Bonsoir. Merci pour l'accueil. En fait le plus gros problème c'est acheter encore plus de livres qu'on a le temps d'en lire. C'est un autre sujet. Le titre est assez long et le sujet du jour ça va vraiment revoir tout ce qui est pour partie base testing et un peu comme Diana ça va pas forcément être un talk très technique parce qu'en une demi heure on peut parler de façon de manière très profonde. Le but va vraiment plus être de revoir les principaux apports que ça peut avoir pour au moins convaincre les gens de creuser plus si le message passe. Une bonne façon de commencer c'est souvent de commencer avec une histoire et en fait l'histoire va être assez plate parce que c'est quelque chose qu'on connaît tous très souvent. J'imagine ça m'a souvent arrivé je crois que c'est très très commun qu'on a un bug souvent production et pourtant le code en question a été couvert par au moins une bonne série de tests mais qui couvraient pas certains codes particuliers, certains valeurs spécifiques ou ainsi de suite. Donc en fait ce que je propose aujourd'hui c'est vraiment de voir d'abord pourquoi on a écrit des tests, qu'est ce que ça nous apporte et c'est quoi les motivations principales pour les candidats. On pourrait passer des soirées complétées là-dessus. Je vais m'en adresser sur le point principal. Revoir tout ce qui est proposé by testing une partie historique parce que ça vient de très très loin et où est-ce que ça on est aujourd'hui qu'on peut l'utiliser. Je vais m'arrêter sur les exemples les plus courants parce que c'est souvent en fait une première barrière d'adoption c'est que les exemples les plus courants sont en général assez mauvais et je me perds de le dire parce que c'est pas comme moi qu'il dit c'est même des auteurs de libraïs qui sont pleines et souvent en fait on rate l'intérêt à cause de ça on passe à côté de la valeur ajoutée et ensuite on va creuser un peu plus sur les mécanismes comment on peut utiliser comme je dis on pourra pas couvrir beaucoup de détails techniques mais j'espère suffisamment pour avoir plus de plus aperçu et fermé en fait en en essayant de prendre du retour sur les objectifs qu'on a quand même tout au départ qu'est ce qu'on cherche en premier test et en quoi ça peut améliorer. Donc voilà ça c'est un peu ce qu'on va essayer de suivre tout au long et la façon dont j'aime voir pour qu'on écrit les tests et là bah on pourrait en parler après la présentation parce qu'il y a autant d'avis qu'il y a de personne mais les deux caractéristiques principales qu'il y a de souvent c'est d'abord pour éviter la bug. Ce qui est important c'est qu'on ne dit pas qu'on veut bien spécifier le programme on veut surtout éviter des soucis donc une certaine certain certificate de qualité et le deuxième qui revient aussi très souvent c'est que les tests aident à documenter le code, à découvrir le code, comprendre ce qu'il est censé faire. Donc je mets ça sous étiquettes, documentation avec plein de variations mais c'est vraiment les deux critères qu'il y en a plus souvent dans des discussions. C'est les deux principaux que moi j'ai ressortis c'est sûr qu'on peut en pour en discuter pendant très longtemps et en fait le but de tout ce qui va suivre c'est de vous montrer comment en tout cas dans mes expériences facées et pour les gens qui l'ont adopté avec qui j'en parle pourquoi tout ce qui est propres par des testings ça permet d'améliorer c'est pas une solution magique mais ça permet d'améliorer ces deux aspects là ce qui est parce qu'il est toujours moins important tout simplement et en fait avant de commencer je vais tout de suite commencer par une parenthèse parce que quand on parle de tests très vite souvent trop vite on parle de tests coverage et en fait c'est intéressant de s'arrêter une seconde pour voir qu'est-ce qu'on mesure quand on parle de tests coverage et puis dans sa métrique avec lequel j'ai une relation amouraine parce que c'est très utile mais dès que ça devient une cible ça devient traduisible mais on est bien conscient que quand on parle de code coverage à chaque fois en fait on va regarder les lignes de code qui ont été exécutées par des tests et le mot clé là dedans c'est lignes de code les codes coverage donnent aucune indication sur la quantité d'état possible et la quantité de la quantité d'état testé que votre code aura pris donc là jusqu'ici ça peut être abstrait on va rentrer dedans plus en détail plus tard mais l'idée c'est que bien justement pour revenir notre histoire du début typiquement c'est genre de bug pour lequel le code était testé c'était on avait testé certains états par contre certaines valeurs clés certaines valeurs limites étaient juste pas couverts dans notre code bien que le code coverage les couvres je généralise mais c'est quand même une histoire qui est très très commune donc c'est quand même vraiment intéressant donc ce qui va être assez assez intéressant c'est que si je reviens sur l'histoire du début le code coverage était vraiment correct par contre ce qui nous manquait c'était vraiment de voir comment partitionner l'espace des valeurs qu'on va pouvoir couler dans notre test pour tester des valeurs efficaces qui vont essayer de couvrir au mieux et au mieux et la notion clé les différentes valeurs qu'on va vouloir tester on pourra pas couvrir forcément l'ensemble d'ailleurs possible parce qu'elles sont infinies donc l'idée c'est comment ce qu'on va essayer de d'avoir la meilleure couverture pour minimiser le nombre de bug donc ça ça remonte très très loin dans l'histoire et en fait l'idée c'est vraiment de voir comment trouver ces valeurs soit par des mécanismes soit par des stratégies donc à rentrer un petit peu dans le détail donc l'idée et quand je parle en fait de partition c'est vraiment parce que c'est le terme qu'on retrouve dans la littérature partition testing ça s'exupplique très très longtemps aussi donc l'idée c'est que vraiment nos partitions vont être implicites ou explicites la plus souvent explicite pour notre code mais on va très souvent avoir des partitions implicites qui vont venir du code qu'on appelle dans nos tests donc admettons qu'on représente une valeur très simple qui prend un seul argument d'entrée sur la valeur x de x des valeurs qu'on va pouvoir prendre il y aura une certaine valeur clé et on va dire au delà de ces valeurs clés les valeurs sont sont valides tout ce qui sera tout ce qui sera inférieur ces valeurs sont invalides si c'est notre code qu'on connaît la valeur clé bah c'est très très facile de tester ça on va créer un test positif également on va créer un test négatif là j'échématise de manière assez rapide mais dans en général on va prendre des valeurs si très proches de la du seuil et on va couvrir relativement bien les différents codes. L'exemple intéressant c'est qu'on a un exemple très simple pour l'instant avec une seule valeur par contre dès que le nombre d'arguments que notre fonction que notre module va prendre on voit très vite que ces partitions vont en fait la quantité partition va exploser géométriquement donc l'idée si on reprend ce que si on a deux arguments d'entrée toujours le même x et puis il y a un autre argument d'acheter un deuxième parment de fonction par exemple qui ce que si donc le x reste toujours x par contre le y on voudrait qu'il sera contenu entre une valeur 0 par exemple et une valeur maximum donc on va se retrouver avec des beaucoup beaucoup plus de partitions ça reste très petit mais on voit déjà que juste avec une ajout de complexité triviale juste une seule valeur on va commencer à augmenter de manière assez assez importante le tourne d'état les dégradés que j'ai mis sont pas inaudits c'est que toutes ces valeurs peuvent aller vers l'infini comment on traite aussi les valeurs infini les tout ce qui peut être des bordements de pile ou un problème d'arrondis ou ce genre des choses on va les avoir donc on voit pas toujours pareil nos exemples positifs négatifs qui seront à peu près toujours couverts nos tests basés sur des exemples par contre couvrir les autres codes va devenir beaucoup plus difficile on peut essayer de partitionner le plus possible déjà on fait beaucoup d'un parti qu'on les fera forcément tous et on voit bien que l'on a un exemple qui reste très simple avec juste deux arguments très très très simple par les qu'est ce qui va se passer quand on va commencer à combiner des infini vous aurez des choses alors le premier exemple qui a venir en tête c'est une division par zéro si la valeur compte c'est pas zéro mais elle est calculée l'intérieur on va vouloir l'éviter encore une fois je prends des exemples simple pour faire passer le message mais c'est montrer qu'on soit partager cette notion de base que la quantité d'étau de nos fonctions grandit vraiment très très vite en fonction de nos impôts donc là le problème qui est qui a supposé à nous c'est vraiment comment choisir les valeurs que ma tesset donc là je vais fermer la parenthèse on reviendra sur ces problèmes de partitioning un petit peu après pour voir les différentes solutions qui ont été apportées à ce genre de problème dans l'histoire et c'est vraiment pas récent parce que en fait ça commence avec les cartes parfois une des choses en 50 où il y a du test random en fait l'idée de base si on vient juste avant c'est en plus du test positif on va juste envoyer des valeurs random en essayant de taper dans les dans ce qui sera invalide pour vérifier que le problème se comporte comme il faut qu'il y ait les erreurs ça l'avantage de fonctionner ça le désantage est assez naïf et peu efficace mais c'est vraiment pas récent on a on a vendu pas l'eau chaude ça date vraiment des tout début l'informatique et non c'est par en deux en fait tout ce qui est random testing qui va être vraiment envie de valeur à toit de tout ce qui est parti une base testing vous l'idée c'est de réfléchir quelles sont ses séparations combien de compte d'écrire pour voir bah quelle valeur va faire tester ça c'est aussi très vieux comme on le voit ben il y a des papiers académiques qui date depuis depuis longtemps là dessus qui en substance démontre que ça apporte une certaine efficacité certaine efficacité est intéressante parce que c'est encore une fois pour une solution magique mais ça peut être amélioré de trouver des bugs mais c'est loin de faire l'animité et de façon pas pour rien que ça existe depuis longtemps que les gens comptent à le faire mais qu'on fait pas forcément dans toutes les équipes non plus si on regarde j'ai l'air plus récemment ça ça nous rajeunit quand même pas donc il y a ce papier des années 90 qui je m'en revue il me semble que c'est une je l'ai parlé récemment il me semble que c'est une météo étude mais l'idée principale c'est qu'il regarde des données sur beaucoup de partenaires testing et l'idée c'est qu'en faire un peu amélior l'efficacité mais les rendements des croissants sont vraiment très très rapidement au delà de quelques partitions le reste est pas mieux que du random donc c'est des efforts en plus pour plus en plus donc c'était un peu leur conclusion c'est ben oui c'est pas utile oui ça aide mais des efforts significatifs pour pouvoir faire forcément grand chose ça a continué encore après où l'idée c'est de montrer vraiment comment faire des tests des stratégies pardon efficace de test sur les partitions les mots intéressants qui sont 6 citations parce qu'on la retrouvait tout de suite après c'est mon stratégie la propriété baisse estique les livres intéressantes pour le faire permettent vraiment de construire les stratégies qui vont éviter toutes ces toutes ces efficacité des méthodes plus anciennes donc ça c'est un peu l'état de l'air archéologique on va dire les mais pour rappeler qu'on n'est pas sur quelque chose de nouveau et si on s'intéresse plus précisément partie de base testing donc c'est arrivé en 99 au départ en rascale et l'idée ce qui est vraiment intéressant c'est quand ils l'ont présenté eux même ils se qualifiaient dans tout ce qu'était randon baisse estique c'est vraiment une façon de générer des données randon donc ça s'inscrivait directement à la suite de tout ce qui est vu précédemment mais avec l'introduction de création stratégie comme je le mentionnais et on voit qu'il y a d'autres caractéristiques qui arrivent avec et donc depuis ça a quand même pris beaucoup de bain beaucoup de plus en plus de popularité ça a été décliné dans beaucoup de langages différents j'ai mentionné juste les deux plus courants qu'ont rencontré bah surtout à l'hypothèse son piton bah d'abord parce que c'est moral pitton mais surtout parce qu'on est choyé la librairie fait vraiment un travail extraordinaire ce qui explique aussi pourquoi ça n'est langage ou c'est plus adopté mais c'est pas le seul si vous allez voir en fait la page de quickshake dans wikipedia vous verrez que des adaptations il est dans 20 ou 30 langages c'est quelque chose de très très appendu donc qu'est ce que ça apporte en fait de plus que du random testing on reviendra sur des caractéristiques plus particulière tout à la fin mais l'idée c'est vraiment d'éviter ce côté boy de force est assez utile et pour finir sur la partie historique après on va rentrer dans le plus technique la la tout ce qui est renommé testique vous le trouvez encore aujourd'hui beaucoup donc tout ce qui est de sécurité en fait tout ce qui est fosing je n'ai pas du tout parlé mais c'est ni plus ni moins que l'exrapolation de tout ce qui était random excusez qu'on retrouve dans différents domaines mais c'est encore très très sur tout très très appendu dans tout ce qui est sécurité et il y a il y a quand même beaucoup de travaux actifs académiques encore dessus donc ça c'est la partie historique on voit que c'est pas nouveau on voit que ça c'est de plus en plus mature et utilisable pour rentrer dedans plus dans des tailles on va prendre un exemple très simple et le titre important comme je m'en souviens c'est un exemple c'est un peu le hello world qu'on va trouver à chaque fois mais qu'il y a l'inconvénient d'être assez mauvais donc on va aller voir plus loin après et commençons par ça l'idée donc on défie une fonction toute bête piton classique à gauche avec un ad on va vouloir vérifier qu'il est commutatif donc le test basique on va vérifier que si on permute l'ordre des opérandes le résultat elle même l'idée pour le faire en piton avec hypothesis c'est vraiment de commencer à mettre des stratégies donc les stratégies on verra qu'on peut écrire nous-mêmes mais il y a beaucoup qui arrivent pour tous les types de base directement dans le langage donc il demandait test le avec deux entiers et donc vous voyez que la fonction test est quasiment la même donc c'est pour ça que c'est l'exemple le plus typique c'est que le code c'est lui lui même même si vous n'avez jamais vu la librairie par contre en le voyant on peut dire tout ça ou autre qu'est ce que ça apporte vraiment en fait ça apporte quelques détails quand même mais c'est vrai que c'est pas franchement le gros effet ou à ou qu'on va attendre pour une propriété given comme ça en fait deux bases peut le customiser dans les dans les décorateurs mais à plus il va générer 50 j'en doute 50 ou 100 va générer un nombre significatif de valeur intéressante pour tester donc en fait votre thèse va t'exécuter un certain match de fois en en plus de ça s'il trouve des des des valeurs pour lesquelles le test fait il va les enrichir dans la cache tant que vous mettez ce cache dans vos artefacts de chez par exemple vous automatiquement c'est test de regression sur ces valeurs d'edge case que vous aurez mais jusque là ça s'est introduit mais c'est pas encore forcément extraordinaire par contre dans notre de notre addition mettons que la fonction soit plus abstraite vous veillez juste que vous testez en permettant de valeur si vous ne savez pas particulièrement ce qu'elle fait comment vous savez quelle valeur sont intéressantes à tester là j'ai pris deux et trois qu'est ce qui fait que c'est plus intéressant que des flottes ou que des 0 ou des choses donc là la réponse classique ça va être lancer des tables de test ou à plusieurs différentes valeurs typiquement de différentes valeurs négatives les essences négatives et quelques quelques valeurs positives jusque le paris est très très classique on voit que par contre ça c'est exactement en fait ce que fait ce que fait hypothèsis sauf qu'il en fera déjà beaucoup plus et dans ses stratégies de base il va aussi essayer de randonner le plus possible ou genre qu'on confrère des flottants il y a des valeurs beaucoup plus intéressantes qui arrivent si on prend des flottants avec quel type de valeur on peut avoir des cas particuliers les cas classiques de fraction de visée par trois sur lequel on soupçonne qu'il y aura des problèmes d'arrondis de chose ou à l'interessante les problèmes d'arrondis avec des des exposants très grands et très petits j'ai déjà eu des bugs assez intéressants qui arrivent des arrondis comme ça donc on commence à avoir des tests en piton classique avec pi test qui vont devenir assez verbe en se demandant pourquoi cette valeur plutôt qu'une autre typiquement voyant la slide j'imagine que vous demandez pourquoi 2.22 quelque chose plutôt que notre valeur à la toute ces valeurs là et beaucoup d'autres vont être génére automatiquement non en fait ce qu'on voit c'est que mon test d'un hypothévisse je vais juste séparer en deux tests avec des stratégies différentes une pour avoir des entiers une pour avoir des flottants et c'est à peu près tout ça ça couvre toujours plus d'états qu'on a donc même si l'addition elle-même n'est pas très intéressante on vous commence déjà à avoir un aperçu à quel point ça peut ça ça peut aider à avoir des tests qui restent lisibles tout en couvrant beaucoup plus de valeur pour essayer dans notre discours le but c'est vraiment de maximiser l'espace des valeurs qu'on va qu'on va couvrir pour être sûr qu'on va cacher les valeurs particulières qui vont que les débuts qu'on va oublier donc par contre pourquoi j'ai mentionné que c'est un mauvais exemple c'est qu'en général parce que ça c'est ça peut simplifier l'écriture mais ça n'apporte pas grand chose de ce qu'on connaît beaucoup mais ce qui est intéressant que j'ai mentionné rapidement c'est qu'on voit qu'on commence à introduire stratégie pour l'instant les stratégies built-in mais on voit qu'on commence à séparer le test c'est à dire la déclaration qu'on fait sur ce que la fonction l'unité testée doit faire son comportement des arguments qu'on va lui donner qui d'habitude sont juste une histoire une anecdote particulière l'on commence en une région de généralisation donc on voit que les tests ont été beaucoup plus visibles pour séparer ce qui est anecdotique des valeurs du comportement qu'on a fait qui est qui est vrai c'est un peu le premier point qui va un peu dévoiler toute la puissance de l'outil c'est qu'en fait très vite vous pourrez avoir beaucoup de stratégies et vous pourrez utiliser ces stratégies en fait vos tests en écrivant les stratégies ça vous force à vérifier vos hypothèses et les pré-conditions de vos tests donc quelle condition ce code est valide peut être appelé ce qui d'habitude avec des tests on le vérifie mais c'est plus ou moins implicite et donc il y a beaucoup de codes ou d'endombres qu'on a tendance à laisser passer à ignorer sans même le savoir avec des tests classiques soit qu'on va découvrir qu'il faut qu'on va se forcer à spécifier avec ça je mentionne ici très vite mais je n'ai pas mis d'exemple dedans juste pour pouvoir tenir dans une demi-heure c'est que ces stratégies on verra qu'on peut en écrire des customs on peut aussi en écrire directement pour des types tout comme là j'ai dit matière pour des anti ou pour des flottes très bien définir un pour une classe custom de votre code un DTO n'importe quoi et en fait de l'oeil hypothesis va vérifier les différents types des champs pour gérer des valeurs qui sont plus ou moins intéressantes là où c'est intéressant et à la fin je mets des liens pour en apprendre plus ce qu'il y a 11 exemples disponibles en ligne pour que vous puissiez approfondir et l'idée principale c'est qu'en fait vous pouvez même pour un type définir qu'elles ont à être les stratégies pour les sous-types donc ça vous permet en fait de ne pas avoir de fixures pour vos tests qui vont être vraiment articulés spécifiques à des tests mais plusieurs des factories définies pour les tests ou en fait dans ces factories hypothesis va faire l'intelligence pour détruire les valeurs typiquement problématiques c'est vraiment les idées principales à renier jusqu'à ça peut paraître très beau mais avec les problèmes d'addition on est tout le temps dans des normes très basiques ce que je mentionnais quand je disais bâtiens pour ces valeurs x ça y ou y ça y ce qui est intéressant c'est de découvrir les partitions à quel lequel sont les valeurs pour lesquelles il y en a des choses qui vont à qui on se passer qui vont être critiques quand c'est d'autres codes en général ça c'est facile à savoir on sait très bien qu'on autorise telle taille maximum que tiens là il y a un risque de division par zéro tout ce genre de règles de falaises en fait d'un côté on est correct d'autre côté on l'est plus on les connaît qu'on est que le code là où ça devient beaucoup plus utile c'est est-ce qu'elles sont définies bien documentées est ce que la documentation est précise dans le code que vous appelez en fait un très bon exemple pour le montrer c'est un bug que la hypothesis avait permis de trouver qui depuis a été correcte si vous le testez ça le test passera aujourd'hui mais typiquement en prenant des time vous demandez le parcerne en le le final les séries et pas non string en iso 86 au 1 donc une chaîne iso format très classique et de leur reparser la date ça marche c'est ce qu'on attend ça marche après tout le temps c'est réversible par contre pour certaines valeurs en fait pour une valeur c'est la cellflocs bug a été trouvé la valeur est juste totalement inconsistente donc depuis c'était correcte mais en fait la question c'est si on s'arrête pour une seconde quels sont les chances quand vous écrivez votre test que ces valeurs là sont des valeurs vous aurez évidemment pensé que tiens c'est une valeur seuil sur laquelle il faut être faut faire très attention donc c'est un peu une preuve par l'exemple par le contre exemple plutôt que toutes ces assumptions pré-condition en fait implicite sur le code qu'on appelle en fait vont pouvoir être testés aussi beaucoup plus facilement donc c'est vraiment on commence à voir le le potentiel aussi de documentation et de vérification de boutique pour compléter les tests pour la suite on va rentrer un petit peu plus dans le détail j'espère que c'est assez grand c'est visible j'essaie de tout faire entrer sur le slide pour montrer un peu juste de mes vraiment un avant-gout très léger de comment composer des stratégies custom donc là c'est un exemple qui se veut relativement générique j'ai un peu anonymisé du vrai code mais l'idée principale en fait les deux premiers blocs je définis deux stratégies la première une stratégie tout bête qui dit bâtiens génère moi des strings à partir d'une regex qui seront des patterns valides le deuxième pour demander de générer des en fait l'opposé des imputines valides pour fermer test négatif les quelque chose d'intéressant tenir dedans c'est le droit par exemple qui va permettre à l'hypothèse de retenir quels sont les paramètres qu'il a pris pour faire ses picrandomes qui font que quand vous le répéter avec le même cible pour répéter exactement la même valeur en fait ce qui permet de faire des tesorégations donc ça c'est généralement tant que vous utilisez la mécanique qui utilise pour faire les stratégies ça sera généralement pour vous et donc l'idée c'est qu'en fait après vous utilisez exactement les stratégies médicine donc c'est ensuite on peut mettre deux tests mon test positif mon test négatif où je vérifie ben tiens quand je fais quand j'appelle cette fonction je vérifie bien que le résultat correspond à l'input que il a été nettoyé par exemple et le deuxième le test invalide mais je vérifie que ça revoise bien la petite décession qu'auquel je m'attends dans les autres exemples qu'on n'a pas parcouru avant on voit le décor à l'exemple par qui il y a l'hypothèse qui permet de spécifier son valeur qu'on veut qu'il soit testé aussi à chaque fois donc ça en fait c'est l'équivalent plus ou moins du pi test mark parameterize on va envoyer des valeurs l'idée là c'est vraiment de le mettre en plus si ça aide à mieux documenter le test typiquement une chaine vide dessus va être tournée dans ce cas là c'est vraiment pour montrer ben tiens ces valeurs là ou un intérêt pour développeur au niveau des tests ça changera à peu près rien mais c'est vraiment plus pour aider le développeur à mieux comprendre ce qu'il va se casse passer et à mieux comprendre le test donc là je reviens sur le point que j'ai déjà fait plusieurs fois mais qui à mon avis est un des points les plus importants ce code là si vous comptez un code qui est fait pi test parameterize ou d'autres amours l'idée c'est avant de séparer le comportement du test d'un côté le comportement du code ce que vous testez dans d'un côté donc dans votre test les celles informations c'est vraiment comment ça se comporte et toutes les pré-conditions toute l'histoire qu'est ce qui fait que c'est valide ou pas est documenté sur les stratégies les stratégies vont dire manière explicite et non non équivoque c'est pas juste quelques exemples c'est pas des commentaires c'est du code qui a documenté vraiment quatre mots pré-conditions donc on commence à voir vraiment beaucoup mieux la séparation entre les deux donc un nouveau développeur qui rentrait dans le code en partant les tests auront une bien meilleure histoire de comment le code est censé se comporter et il sera pas obligé de deviner suivant quelques exemples de devoir l'extrapoler lui-même et faire des hypothèses qui seront bonnes ou incorrect c'est vraiment des points clés je pense qui apporte beaucoup pour le développeur pas forcément encore pour comme et vraiment pour le pour le développeur donc je c'est de ne pas c'est vite sur beaucoup de petits points j'essaie de les récapture vite fait le point clés c'est vraiment la stratégie qui vous permet de séparer le code de séparer par bon les inputs de les généraliser pour vraiment documenter votre code je sais que je me répète mais c'est le point important qui m'en fait qui aide à vraiment documenter tout ça et donc l'idée c'est qu'aujourd'hui vous voyez que vous avez souvent des fixtures que vous allez utiliser et en fait bah comme c'est des valeurs hard-coded ou c'est des exemples très spécifiques dans certains tests ça arrive trop souvent qu'on va vouloir réutiliser des fixtures en op dt1 et puis il va casser notre test à tout ce côté fragile là qu'on a trop souvent en fait et par définition remplacé dès que vous n'en passez pas de stratégie parce que bah vous appartissez de généralisation là donc votre fixture souvent soit correct soit incorrect mais vos tests ne pas basé sur les exemples les deux derniers points cette slide sont intéressants le shrinking je n'avais pas encore parlé du tout et en fait c'est un des éléments principaux qu'il y a la plupart délibérés de propres testings à apport comparé au genre random testing on parlait plus tôt je mentionne la plupart parce que dans tous les langages ça peut encore être ajouté ça fait très bien pitton l'idée c'est très intéressant quand ça vous trouve un bug donc apothésie j'ai dit sur une stratégie va générer 50 non plus tom d'input que vous lui demandez et si tu trouves une valeur qui va faire fail test il va pas vouloir tourner tout de suite avant de leur tourner il va essayer de la réduire et donc la réduire dépend du type de donner typiquement pour une chaîne il va essayer de trouver la chaîne la plus petite qu'il a qui a reproduit cette erreur là pour un entier un point un nombre il va essayer de trouver le petit par exemple vraiment c'est trouvé la valeur limite qui fait que là ça fail et avant ça passe donc en fait vous donne il va pas vous juste vous dire tiens par là bas votre test fail il va essayer de vous mettre vraiment très proche la partition que vous avez raté donc si on revient à l'image de départ avec les zones rouges à verte le but c'est que vous définissez à croire son vos zones et peut-être que dans le code que vous appelez vous avez raté des partitions qui font que vous avez avoir des petites sections vertes qui devraient être rouge ou l'inverse et donc l'idée c'est que ma apothèse va faire des tests à droite à gauche base stratégie donc les petites crocs j'ai fait il va prendre des valeurs rondom pour faire ce test à saison quand il y a un qui est faux il va vraiment essayer d'excuser de réduire cette valeur là pour s'approcher plus près et découvrir en fait la partie où vous avez raté donc ça c'est vraiment intéressant parce que quand vous avez un test qui fail la valeur vous donne beaucoup plus d'informations sur pourquoi ça fail que si c'était une valeur purement en domes tout ce qui est reproductabilité j'ai un doute sur le thème français mais vous l'avez compris c'est ce que je mentionne c'est que dès que des tests ont failé les valeurs de sils qui ont été utilisées pour générer sa valeur en domes seront sauvegardés les contes les valeurs qui ont en fait toutes les données pour rejouer exactement c'est ces valeurs qui ont fait fail les tests sont sauvegardés donc tant que vous gardez ça dans votre cache ancien si n'importe comment vous l'archifiez mais vous le refornissez pour les prochaines run bah tous ces tests seront automatiquement exécutés pour la rénovation donc ça ajoute aussi en fait ça vous fait vos tests de régulation automatique entre guillemets ça ne remplace pas d'ajouter des textes explicites genre les exemples que vous avez mentionné pour les l'irrigation qui donne plus d'informations pour tient attention c'est des valeurs pièges qui a d'aussi développeurs à mieux comprendre les cas limites mais en fait ça vous apporte ce double bénéfice donc là j'ai fait une espèce de parcours très très très rapide de bbt mais pour montrer depuis des exemples de base donner des avant vous vraiment de comment les plus loin si on regarde un peu les promesses que j'ai fait au début les premiers on sur la qualité sur la documentation du code bah sur la qualité j'espère que j'ai un peu fait le point en montrant que ça va commencer à trouver des cas que l'on n'a pas pensé l'exemple du format est assez assez parlant pour ça le le coup de la documentation est trop peu souvent mentionné alors que bah souvent en fait la plupart des bugs concrets c'est parce que le modèle mental du code qu'on a est incorrect ou qu'on a raté des assumptions ou genre de choses le fait d'être forcé d'écrire des stratégies et donc d'être explicite à propos de ce que notre code prend comme comme valent valide ou pas force des fois même à découvrir la bug à vendre ou les tests juste qu'en écrit que facilité d'aider ou pas le fait de vous poser et de mettre par écrit les conditions et de beaucoup à se rendre compte que bah tiens telle zone n'a été pas été pas qualifiée on sait pas comment ça devrait se comporter ou genre de choses donc c'est vraiment c'est pas une solution magique mais ça aide vraiment bien donc jusqu'à j'essaie je mets beaucoup de points positifs on va quand même essayer de prendre du recul parce que c'est comme n'importe quel outil j'ai pas une si ça si ça résolver tout le problème ça serait quand même encore plus répandu même si ça a plus en plus de succès mais c'est moi un outil de plus qui complément bien le reste de votre votre outil que le but c'est pas d'abandonner tout le reste mais c'est quelque chose à considérer si vous si vous voulez vraiment c'est d'améliorer la catégorie du code et la station de jikstra que j'avais mis au tout début qui m'ont semé que les tests pouvaient juste l'existence de bug mais jamais enfin ou l'absence mais jamais que le code est vraiment correcte ou qu'il n'y a pas de bug qui sont pas détectés ça aide la property testing aide à s'approcher plus de l'absence de bug parce qu'on couvre beaucoup plus d'état mais toujours pas de garantie à 100 % dessus en fait pour les garanties formelles ça pourrait être le suivi d'un notalk sur tout ce qui est méthode formelle mais qui en général sont plus côté algorithmique parce que pour le faire sur du code aujourd'hui il n'y a pas encore de solution magique donc pratiquable au quotidien il y a des solutions théoriques qui marchent très bien pour des scopes très limitées pour du piton quotidien on n'est pas encore là mais c'est ça donc c'est un peu ce qui s'en rapproche le plus sans avoir tous les bénéfices et je me finis par mentionner quand même un contre-argument qu'on retrouve régulièrement qui dit bah tiens grâce au property testing j'ai trouvé des bugs et donc le contre-argument souvent c'est parce qu'on n'est pas assez bon pour qu'il déteste ce qui est possible potentiellement vrai mais c'est un peu un fausse argument en fait mon point c'est oui c'est vrai mais c'est exactement l'argument que bah pourquoi on disait pourquoi il y a plusieurs ondous pourquoi il y a des monités en couleur ben pourquoi on refise le progrès c'est oui si je m'arrête beaucoup que je creuse beaucoup dans le code que j'appelle je pourrais réussir à trouver toutes ces partitions par contre c'est un outil maide à lui faire de manière beaucoup plus efficace je peux passer beaucoup plus de temps sur la qualité si un outil maide à être plus efficace je serai stupide de juste pas le considérer que j'utilise ou pas après c'est un choix mais au moins être rationnel à propos de mon choix donc c'est c'est pas que c'est pas que pour les gens qui sont fainéant ou mauvais en test c'est aussi si on va être juste plus consensieux et donc en fait l'idée c'est que tous les tests dans cette pyramide je mets souvent compiles ça peut être votre type my pie ou autres choses ou pour les engages complets complets mais l'idée c'est tous les tests de correctness du code ça c'est la pyramide vraiment classique la façon où on le voit bien simplement dans les différents projets que j'ai utilisé c'est vraiment toujours un complément et surtout en test unitaire mais aussi des tests intégrations ça marche très bien je suis là pour tester beaucoup plus de scope d'input surtout que les tests intégrations souvent ont beaucoup plus de code appelé donc vous laissez sure de vérifier tous les toutes les préconitions de chaque chaque partie de code pour finir je vais passer juste très rapidement mais je vais mentionner parce qu'il est mérité et je parle mais vous avez le temps de les lire en détail tous des slides et des sessions pardon de David McIver qui est l'auteur de hypothesis en fait qui a porté quick check en piton et en fait je les résumé très rapidement pour pour clôturer ça mais l'idée c'est vraiment en fait il répète un peu ce que j'essaie de dire depuis 20 minutes une demi-heure mais de manière beaucoup plus explicite que c'est vraiment pour me forcer à documenter les assumptions pour être sûr qu'on teste le plus de cas possible celle que j'aime beaucoup c'est celle-ci où il mentionne vraiment que le but c'est de de rendre le test en fait plus fiable ce que je mentionnais qui se traduit le plus souvent dans mon expérience avec des fixtures qui deviennent un peu fragiles c'est bon quelque chose que ça peut améliorer donc typiquement si vous voulez essayer de l'adopter l'idée c'est de commencer à remplacer des fixtures par quelques stratégies et le saut poudrerait par noir là où ça peut avoir le plus de valeur là vous avez le plus des stocks ou un inexploré donc toutes ces celles là seront dans les slides que je partagerai après et en fait juste pour clôturer c'est pas les liens vous pouvez faire des captures d'écran mais j'ai partagé les slides ça sera beaucoup facile de cliquer pour creuser si ça vous intéressez que vous voulez apprendre beaucoup plus le website est évidemment la première ressource mais ce qui est intéressant c'est aussi beaucoup ce que les gens ont écrit dessus donc David McIver de l'auteur d'hypothesis avait fait tout un essai dans une carte mague l'année dernière qui montre vraiment beaucoup la valeur c'est il y a des exemples techniques plus développés que ce que j'ai temps de faire ici et qui montre la valeur beaucoup d'articles comme ça donc si ça vous intéresse vous allez vraiment lire commencer par ces liens là qui sont vraiment intéressants et avec ça merci beaucoup pour votre temps et j'espère que ça aura motivé des gens à essayer d'explorer ça. Merci beaucoup Sébastien et je vais laisser John diriger la session des questions. Alors il y a une question c'est get valid stuff que vous avez je sais pas c'est moi qui l'avais manqué. C'est un exemple que c'est quoi exactement dans les codes? En fait je vais volontairement laisser flow parce que ça peut être à peu près n'importe quoi. L'idée c'est si on prend du pi test classique on en a une fixture pour avoir un get valid quoi que ce soit vraiment avoir une valeur valide une fixture que tu as retenue dans plusieurs tests et donc tu ne veux pas répéter là à chaque fois tu la mets dans une fixture que tu vas appeler tu prends la remplacée par une stratégie qui est au point juste une valeur exemple ou quelques valeurs générées à partir d'exemples va être basée sur les stratégies. Je sais pas si c'est clair mais l'idée c'est ça c'est vraiment de remplacer une une une fixtures plus ou moins encodées par quelque chose qui est beaucoup plus dynamique. Il y a une autre question c'est existe-t-il des séries de tests reconnus globalement ou internationalement qui permet de certifier la qualité d'un code selon les normes de qualité? C'est une très bonne question qui pourrait qui pourrait souvent très sérieuse soit presque sarcastique des fois à ma connaissance rien du rien qui facilite la milité c'est parce que souvent les normes le problème des normes vont pas être là pour la qualité vont plus être là pour aider le process. Je pense à tout ce qu'il y a dans miso ou même d'actualier vers des dans de sécurité vont certifier on des process t'assurer que certain checkpoint et puis le cool ce qui est un vraiment intéressant dans la question c'est le critère de qualité du code ce que juste la définition de qualité va être traité variable en fait une série de tests t'aidera plus à mesurer la robustesse d'un code que sa qualité. Je sais que je jouais un peu sur les beaux mais c'est qualité tellement ambigu comme terme que c'est une question sur laquelle je m'avancerez pas trop ou après quelques bières pour répondre. Honnêtement pour la qualité d'un code ce n'est pas tant pour le code mais ce que je m'en souviens surtout ce qui est méthode formelle c'est ce qui s'en penchant plus parce que là il y aura des preuves et le mot preuve est important des preuves que l'algorithme est correct pour tous les états possibles. Donc le plus dur après c'est en général pour faire ça tu as besoin de faire des approximations donc tu ne le fais pas vraiment sur du code tu le fais sur une modélisation de ton code et le diable doit être dans tous les détails pour après traduire l'implantation. Donc c'est une réponse très longue pour dire pas ma connaissance. Il y avait une dernière question mais c'est un peu plus vague je ne sais pas si c'est moi qui l'avais manqué. Comment on peut rendre le test un peu plus résilient parce que vous avez parlé des résilience. C'est une bonne question mais ça dépend de manière général où est-ce que les suites de tests sont faibles. En fait on met pour partie d'accessing à part. Le cas ideal c'est que ton test va être totalement atomique il sera entre guillemets pas fragile. Le souci qu'on a le plus souvent dans le quotidien c'est que le volume de tests augmente tellement que tu veux essayer de réutiliser. En fait c'est le lock des fixtures que tu as commencé à repartager entre les différents tests qu'on s'est utilisé et comme elles ne sont pas par définition générique c'est là que des fois les assumptions que tu vas faire sur certaines fixtures ne vont pas être celles qui vont marcher pour tous les tests. Donc en fait mon point c'est oui les stratégies en fait elles beaucoup à ça parce que ça va te forcer à ce que ton cas soit générique. Donc en fait ce que j'ai envie de lui mentionner c'est quand tu écris une stratégie ça te force à ce que ton test soit résilient pour un seul test donc si il le utilise pour un autre soit il marche soit même la logique de ton cas n'est pas bonne c'est pas le test en lui même qui marche pas c'est en lui même. Donc en fait l'effort tu fais un amont et après tu es un truc qui m'est débarrassé de ça mais ça dépend enfin faut vraiment commencer mais en fait c'est comme n'importe quoi faut faire une boucle de feedback pour voir qu'est-ce qui rentre dans ce fragile pour commencer parce que je parle beaucoup du problème des fixtures fragiles qui sont le cas le plus courant pour moi je sais pas du tout si c'est la même expérience pour tout le monde. Ok c'est comme si ça basé sur les erreurs aussi qui ont été découverts ou à l'écodeur. Ok et je vérifie s'il y avait d'autres questions on n'a pas encore d'autres questions. Attention je suis dans le Slack après j'ai quelqu'un j'ai partage aussi les liens. Super bien merci beaucoup Sébastien et comme Sébastien l'a mentionné il va rester avec nous sur Slack peut-être c'est quoi ton alliant sur Slack et Sébastien ? C'est une très bonne question. Je me vérifie parce que je dirais que je vais rejoindre plusieurs années c'est pour Sébastien ou je ne sais pas. Je passerai un message vous verrez ce qu'il y a. Excellent question très pertinente et donc Sébastien va rester rejoignable sur Slack et peut-être qu'il va pouvoir se joindre à nous pour notre 5 à 7 virtuel sur JT. Donc j'ai trois petites annonces de clôture donc on invite tout le monde à se joindre à nous sur le 5 à 7 virtuel sur JT. C'est facile c'est juste une petite vidéo conférence ensemble on invite tout le monde à aller chercher le rafraîchissement favori et puis on va parler de code ou pas de code. La discussion qui est la plus intéressante pour vous ça va être celle qui va suivre et on va voir notre soirée pandas mardi prochain. Le lien pour la soirée pandas est dans la description du canal YouTube puis on va la mettre sur Slack aussi pour être certain que tout le monde le trouve et on a le sondage de satisfaction s'il vous plaît remplissez le sondage de satisfaction parce que ça nous aide beaucoup à savoir quel genre d'événement on doit faire, quel genre d'inviter on devrait avoir et puis à quelle cadence on devrait avoir tous ces événements fantastiques. Je répète le tout en anglais et je vous remercie pour l'hôpital, il va être sur JT, le URL est là-bas, ici, piMTL, meet.fgnr.ca, évent 87, c'est juste une vidéo conférence, prends votre favorite drink et on va parler de code ou de quelque chose d'autre, ça vous fait plaisir. On va avoir notre evening of programming practice on pandas la semaine prochaine, la semaine prochaine, le lien pour ça est dans la description sur YouTube et puis nous avons aussi dans la description sur YouTube le URL pour notre surveillage de satisfaction, s'il vous plaît, parce que ça nous aide vraiment à savoir quel genre de gens on devrait inviter, comment on devrait faire des événements, quel genre d'événement on devrait faire, je ne sais pas ce que vous faites, donc s'il vous plaît, c'est tout pour aujourd'hui, on vous voit peut-être la semaine prochaine ou si pas, en septembre pour le Pied-Mont, 88. Merci encore Sébastien et puis on se voit sur Ducit. Merci beaucoup à Kaleem. Bye, au revoir.