 Bonne soirée encore ! Nous sommes B2CK, Cédric Vier et Nicolas Everard et nous allons parler de tester votre code avec Python. Nous sommes tous B2CK shareholders. Python développeurs depuis 2001 et Triton développeurs depuis le début de Triton. C'est donc 10 ans. Triton est à l'arrivée de Python en utilisant PostgreSQL, c'est un backend. Avec un client GTK, un client web, Triton et JavaScript. Il y a beaucoup de codes, parce que c'est la timeline de la ligne de code que nous avons depuis le début. Nous sommes autour de 400 000 lignes de codes. Avec ce nombre de codes, ça commence à devenir difficile ou ça commence à être un problème. Quand vous faites un changement dans une grande base de codes, il faut être sûr que vous n'allez pas briser quelque chose dans l'application. C'est pourquoi la testation est importante. Pourquoi nous évoquons un test ? Le premier est d'être sûr que le code que nous évoquons maintenant, c'est le code que nous espérons. C'est important. Nous voulons assurer le correctement de la code, mais pas seulement aujourd'hui, mais aussi demain et dans 10 jours et 10 ans. Nous avons fait un changement dans un endroit et nous voulons travailler de toute façon dans 10 ans. Avec tout le changement que nous avons fait. C'est pourquoi la testation, maintenant, c'est un problème pour vous, parce que vous ne voulez pas faire le même test d'aujourd'hui. C'est important de faire un test pour ça, qui va être automatique. Un autre point, c'est que si vous avez trouvé un bug dans votre code, vous ne voulez pas avoir le même bug d'aujourd'hui. Donc, le meilleur moyen de faire un test est d'assurer que ce bug ne reappeint plus tard. Donc, vous avez eu un test quand vous fixez un bug, habituellement. Et le dernier point, c'est que si une base code évolue, c'est comme ça, vous ne pouvez pas être à la première fois sur tout, sur quelque chose que vous pouvez, mais sur tout, c'est impossible. Donc, vous devez rewrite parfois une grande partie de votre code et d'avoir la confiance que vous n'aurez pas oublié, vous avez le test pour que vous changez ça. Par exemple, quand nous avons switché de Python 2 à Python 3, le test nous a aidé à assurer que les tools automatique que nous avons utilisés n'auraient pas brisé quelque chose. Il y avait des bugs, bien sûr. Et aussi, ce qui vous donne un test, c'est d'être sûr, vous avez la confiance de changer votre code. Vous n'êtes pas plus affrayés de changer ou d'improver quelque part, parce que vous savez, grâce à votre test, que vous n'êtes pas brisé quelque chose, mais juste de faire le code meilleur par refactoring de changer quelque chose. Oui. Tout d'abord, un test. D'ailleurs, il y a différents types de tests pour... quand vous développez. Nous avons le test unique, l'intégration, le test fonctionnel, les tests qui sont générés et vous pouvez aussi tester la performance de votre application. Donc, juste... C'est une outline d'un test qu'on va parler de. D'ailleurs, si vous voulez interrompre nous, s'il vous plaît, nous ne vous ferons pas bâtir. Il y a des bonnes pratiques quand vous faites un test. Le premier est de faire des tests qui sont isolés. Le deuxième c'est que votre test soit reproductible ou que vous faites un test déterminique. Donc, le résultat ne change dépendant de la condition externelle. C'est bien de le faire vite. C'est mieux de faire un test simple parce que vous ne voulez pas aussi débloquer votre propre test parce que vous faites des tests dans votre test. C'est mieux de le faire simple. Et automatique, le test est aussi bon parce que d'ailleurs, vous n'oubliez pas de le faire et vous commencez à accumuler l'issue. Oui. Qu'est-ce que vous vous direz par isoler le code test? D'accord. C'est le next slide. Par isoler le code test, c'est que quand vous runz un de vos tests, il ne dépend d'avoir d'autres tests en avant ou d'autres tests en après. Donc, vous devez pouvoir faire ce test seul. Et il ne change l'état. Après le test, le software est en le même état qu'avant le test. Comme ça, vous pouvez faire des tests dans d'autres ordres d'interface avec l'autre. Et donc, vous n'avez pas d'effectifs. Et le bon point, si vous write un test comme ça, c'est que vous pouvez runz votre test en parallèle et donc, faites-le plus vite. Ok. Donc, je n'ai pas beaucoup à faire. Oui. Oui. Oui. Oui. Pourquoi le test doit être reproduisable ? Reproduisable. Ok. C'est pour éviter le cas commun que nous avons vu à moins une fois dans la vie. C'est le cas où votre professeur ou votre professeur, je ne sais pas, c'est pas broken, mais c'est pas broken sur votre computer. C'est pour éviter ce syndrome. Ça fonctionne sur mon computer et je n'ai pas besoin de fixer quelque chose. Et donc, une façon de faire ça c'est d'utiliser des impôts statiques pour votre test. C'est une bonne idée que vous pourriez avoir. Je test avec quelque chose. Mais non. En fait, c'est une bonne idée. Encore une fois, si vous avez besoin d'utiliser les normes, votre test devrait vous donner si vous avez faim, quelle valeur vous utilisez, comme ça vous pouvez reproduire avec le même état. Parce que parfois, vous runz le test dans un... Par exemple, nous avons eu cette question quelques semaines auparavant. Je ne me souviens pas. Nous avons usually runz le test durant le temps de l'office et pour quelque chose de la raison que je travaillais, c'était 11 o'clock à la nuit. Je n'ai pas fallu. Et je n'ai pas compris pourquoi. Parce que, évidemment, je n'ai pas changé cette partie de la code. Et la raison c'était que le test était dans la zone de temps de... Je dirais Japan, mais ce n'est pas Japan. Je ne me souviens pas le nom de la zone de temps. Et c'est parce que nous n'avons pas le temps dans le test. Et c'était déjà un autre jour dans le Japon en Belgique. Donc, nous avons un problème. Et pour ça, il y a des libraries qui vous aideront à éviter ce genre d'issues. Par exemple, c'est FrisGone. C'est un library Python que vous pouvez utiliser pour décorer votre test. Et ça va fixer le temps ou le temps durant le run de votre test. Donc, ça change les méthodes qui vous donnent le temps et le réplique pour fixer le temps. Donc, vous pouvez... Vous êtes sûr que votre test est toujours en train de faire le temps spécifique ? Et vous devez aussi s'occuper parce que parfois la randomité est faite. Par exemple, nous avons eu un bâtiment récemment de la variable qui est... Je peux m'expliquer ? Oui. Il y avait un test une partie de la code qui était à un moment reliant sur l'ordre de la clé d'une dictionnaire en Python. Et l'ordre de la clé dépend de toute la méthode de Python qui est la clé Python utilise une clé au début du temps de la clé qui est la randomité qui fait la méthode pas stable. Oui. Ou c'est différent pour chaque run. Donc, c'est la protection contre des attaques. Et puis dans un cas le test était en train d'assurer que la clé s'occupe un peu différente et la code s'est faite. Mais grâce à les outils qu'on utilise nous connaissons la clé qui était en train pour ce test et donc nous pouvons reproduire et comprendre ce qui se passe. Donc à un moment nous trouverons le bug et faire la code n'a plus dépendant de l'ordre de la clé. Oui. Merci. Donc, votre test devrait être rapide parce que pour une simple raison vous n'avez pas besoin des développeurs pour ne pas faire le test. Si ça prend 5 minutes pour faire le test ils vont lancer le test alors qu'ils travaillent ils vont attendre pour le test 5 minutes c'est assez longtemps donc ils vont lancer le test et ils vont prendre pas de temps pour lancer le test et ils n'ont pas d'informations que le test a fail. Donc, vous voulez que le test soit rapide parce que ça aide dans les développements. Non mais même si ils ne vont pas lancer le test. C'est aussi ça qui vous aide si vous pouvez faire juste la partie du test. Donc, souvent, vous travaillez sur des méthodes spécifiques ou des objectifs et donc, vous voulez que vous puissiez faire le test juste pour cette partie quand vous en développez comme ça, c'est plus rapide vous avez le feedback plus rapide et bien sûr, à la fin quand vous pensez que vous êtes prêts pour le comité vous travaillez le test pour tout Et donc, pour être rapide les choses communes pour ne pas c'est de faire extrêmement grandes computations ou d'utiliser des connections ou de connecter à un database etc. Donc, oui ça vous permet d'être un peu plus rapide. Il y a aussi le setup parfois le setup de votre application avant le test serait plus rapide donc, c'est mieux d'improver et faire plus vite. On peut peut-être expliquer ce que l'on fait avec le backup pour Triton c'est donc pour quelque part du test on veut utiliser le stack avec le database et tout pour être sûr que ça marche en créant le tout database chaque fois au début du test ce que l'on fait c'est qu'on crée le database et après ça on fait un copier, un dump et on restore le dump pour chaque autre test donc on a un fresh database mais c'est très rapide parce qu'il y a un dump et quand vous êtes développé c'est un dump donc c'est très rapide pour faire le test et faire le database oui, on peut réduire le temps 30 fois ou quelque chose comme ça je ne m'en souviens pas je pense que pour un test on va faire 1 minute 2 ou 3 secondes oui, c'est vrai ce matin, j'ai dû récréer le database et le test après ce matin c'était 2 ou 3 secondes c'est une grande victoire pour prêter la particularité le database est créé de la classe donc c'est une grande machine c'est vrai oui, le test devrait être simple comme je l'ai dit pour cela, vous devez être careful de tester votre code et pas votre dépendance vous devez considérer que votre dépendance est déjà testée testée d'autre côté dans votre code donc, focusz sur votre propre code seulement mais, bien sûr, ne fallez pas faire 2 tests qui sont trop élevés parce que le test n'arrête pas l'issue donc pour cela vous devez tester le comportement de votre code et pas l'implémentation à un moment, vous devez essayer votre test sans vraiment regarder votre code mais, juste juste en pensant à ce que cette fonction fait exactement et à ce que je veux cette fonction pour faire et non, ok, je vais pour exemple, l'exemple classique est la fonction factorial vous pouvez l'écrire dans de nombreuses différentes manières mais au final, nous savons ce que nous voulons tester c'est que la définition de l'exemple de la mathematical c'est un peu un exemple et chaque test doit être focussé sur le test d'une certaine façon que quand ce test est faible, vous savez exactement où est le bug normalement vous ne devriez pas débugner vous-même la fonction de l'exemple ou de le repliquer vous devez savoir exactement où est le bug, parce que le test doit être focussé sur un certain test ou comportement que vous savez où est le code, ce serait possible et et aussi faire le test simple va les faire plus facilement parce que même si vous êtes seulement testant le comportement parfois votre API va changer et vous devez changer votre test et adapter à ces changements le test ne devrait pas devenir un bloc pour vous pour éviter votre code vous devez pouvoir éviter les deux et il ne devrait pas être un pain pour éviter votre test sinon c'est productif et donc le test doit être automatisé et pourquoi doit-il être automatisé pour cela, nous utilisons les tools d'intégration en fait, nous utilisons le drone mais en Python, vous avez le build button et le Jenkins c'est pas Python et donc ça vous permet de faire le test sur chaque comité donc vous êtes sûrs que chaque comité est vraiment testé les gens devraient le faire mais vous n'êtes pas sûrs qu'ils le font si vous avez un outil qui le fait pour vous c'est extra et aussi comme ça, vous savez quel comité, quel changement brake votre test vous avez un hint sur qui était le build oui et pourquoi il a breaké et aussi avec un outil d'intégration vous permettrez de tester les environnements parce que les développeurs ils testent seulement sur leur computer et ils permettent de tester ce que je pense sur différents bases de données mais je sais que ça sera testé de toute façon, sur des matriques de l'environnement par exemple, on peut tester le SQL SQLite dans différentes versions de Python, même Python 2.7 et ainsi et bien sûrs, quand il break il vous permet de envoyer l'email à les gens qui ont poussé ce comité et ils le poussent pour être responsables de leur code et fixer et ne pas attendre quelqu'un d'autre pour faire ça donc les outils qui sont disponibles dans Python pour tester il y a juste des noms mais le grand le premier c'est de Write your test case le laboratoire standard il y a déjà quelques outils il y a les tests uniques qui sont c'est un outil c'est un outil de java il y a aussi les modules qui sont d'autres outils de writing test et vous avez maintenant le mock qui vous permet de boire quelques objets mais on va parler d'un mock après ça quand vous avez votre test case bien sûr vous avez besoin d'un run donc vous avez besoin d'un runner par default vous avez besoin d'un test avec un runner et sur la version récente de Python vous pouvez découvrir les tests automatiquement mais il y a d'autres outils comme PyTest Nose et Docs peut-être vous pouvez parler de Docs ? oui pas pas beaucoup PyTest est probablement l'un des les plus populaires des runners d'ailleurs c'est bien parce qu'il n'y a pas un code boiler comparé au test unique mais en fin on n'a pas utilisé PyTest et on a stické d'un test unique parce que ça fonctionne bien pour l'utilisation et la feature extra de PyTest on a plus de complexité donc on n'utilise d'un test unique et on utilise Docs parce que Docs est un outil qui vous permet d'utiliser d'autres environments Python et ça s'est automatiquement utilisé pour vous donc c'est un très bon outil d'utiliser si vous avez un software qui devrait fonctionner pour une version Python puis il y a un développement de comportement c'est où vous définissez l'application avec usually et de toute façon votre application réacte donc il y a usually 3 keywords l'une où vous dites Given j'ai cette fonction et cette data quand je fais ça j'espère avoir cet résultat qui en théorie permet les gens qui n'ont pas utilisé d'utiliser des tests et d'utiliser des codes d'utiliser beaucoup de tests parce qu'ils sont des gens fonctionnels ils sont des gars marketing je ne sais pas et ils doivent pouvoir utiliser ces récipes récipes mais on n'a pas vraiment essayé parce que vous devez faire beaucoup de matchs pour définir beaucoup de choses et on n'était pas vraiment convaincés par cette approche donc parce que vous devez transformer la sentence dans un code réel et à la fin c'est probablement plus rapide d'avoir un code et vous avez aussi des outils pour vous comme l'hypothèse donc vous définissez un set de votre input de quel genre d'input votre méthode s'exprime et de quel genre d'outils il doit donner et les outils vont générer une valeur dans ce sub-set pour tester l'outil pour vous donc c'est un test automatique généré et l'hypothèse est un peu clé parce qu'il y a des valeurs critiques comme non zéro petits numéros un petit peu plus donc c'est un petit pour récapituler ce que l'on voit donc on a des tests différents et maintenant on est en train de regarder l'unité test ce que l'unité test c'est de test les petites parts de votre code donc généralement la fonction en Python donc vous allez tester une fonction dans un test et généralement le test c'est de mettre des outils fixer l'outil et de tester de donner des outils ce que vous espérez donc vous testez votre fonction si c'est un black box c'est une fonction que vous avez le right output selon l'input et bien sûr vous devez être un peu cléveur sur quel genre d'input que vous allez tester oui, vous savez votre programme donc vous savez les cases critiques de toute façon la bonne pratique pour faire les tests d'arranger votre code d'une certaine façon c'est facile de comprendre le test donc la première partie c'est d'arranger votre code votre setup oui, vous avez préparé tout pour votre test donc si vous devez définir des objets d'input après ça, vous faites seulement un acte donc c'est peut-être juste de coller les méthodes et après ça vous testez le résultat donc votre assert c'est exactement ce que vous expliquez et vous devez avoir plusieurs asserts parce que vous devez non normalement vous devez faire seulement un assert pour chaque test parce que vous êtes testant pour chaque test si vous commencez à avoir plusieurs asserts le problème est que le premier assert va falloir mais vous ne verrez pas le résultat de l'autre assert donc vous devez essayer de faire seulement un assert et peut-être tester dans votre assert plusieurs choses mais c'est le problème après ça pour les tests unis vous devez tester seulement un assert parfois votre assert dépend d'une autre assert ou d'autres objets qui sont interactifs avec la partie des asserts et vous devez éviter donc c'est où les objets appartiennent peut-être mais avec notre expérience avec des choses que vous devriez essayer d'adverter c'est compliqué de maintenir parce que chaque fois que vous changez l'internel de votre méthode ou toutes les objets que vous devez changer de rewrite votre assert et d'assurer que c'est correct c'est avoir votre code parfait la première fois c'est très difficile parce que vous refactez beaucoup et donc vous devez ajouter l'application de refacteur aussi un refacteur de la grande partie de votre assert si vous avez beaucoup d'objets donc vous devez vous bloquer si vous avez trop d'objets ça va vous bloquer d'une certaine façon parce que vous devez bien sûr si le monde était parfait si vous étiez parfaits l'objet serait idéal mais ce n'est pas le cas et aussi on dit que vous devez tester le comportement de votre méthode et pas l'implémentation et en quelque sorte en utilisant un Mock on commence à tester votre implementation et pas le comportement aussi un autre point qui est probablement un peu controversé mais on pense que vous devez essayer d'adverter à la designer de votre API d'améliorer l'injection c'est un moyen commun d'isoler votre méthode pour être sûr que vous avez une petite partie de code que vous pouvez tester c'est d'injecter la dépendance je ne sais pas si tout le monde sait ce qu'est l'injection la dépendance je sais c'est si votre méthode a besoin d'exemple un module pour qu'on appelle un module c'est-à-dire Deadtime le module Deadtime en Python pour obtenir la date en instant d'utiliser l'importance de Deadtime directement et de l'utiliser dans votre méthode vous avez un attribute de votre un argument de votre méthode qui contient le module Deadtime que vous pouvez changer avec quelque chose d'autre d'exemple un objectif et donc vous n'êtes pas dépendant d'un test ce n'est pas l'utilisation d'un module Deadtime mais ce que vous voulez c'est un moyen d'être capable de tester le résultat d'avoir l'effectif d'un module Deadtime le problème c'est que vous changez votre API d'améliorer les tests et peut-être votre nouveau API n'est pas si bon parce que peut-être vous avez beaucoup c'est un peu artificiel de l'API parce que vous faites votre API artificiel juste pour le sake de tester et donc selon nous c'est toujours un bad sign et votre code c'est un peu comme spaghettis parce que si votre méthode s'appelle d'autres méthodes qui nécessitent aussi d'injecter des dépendances qui utilisent d'autres méthodes qui ont d'autres dépendances etc. vous commencez d'injecter beaucoup de dépendances sur un méthode parce que ça s'appelle d'autres méthodes et pas pour vraiment l'application c'est aussi une bonne pratique d'utiliser des tests dans Python vous devez utiliser, quand vous write votre fonction test, des méthodes test explicit doc strings parce que les testrunners vont vous montrer les doc strings et donc quand ça s'arrête vous devez juste lire les doc strings et vous devez savoir exactement si vous avez le nom de la fonction ok c'est un bon rappel mais avec les doc strings c'est plus facile aussi vous devez utiliser assert equal d'autant d'utiliser assert a equals b parce que vous donnez une question parce que si assert equal fails vous avez d'autres informations sur la valeur a et b et vous pouvez faire la comparaison vous-même il y a beaucoup d'autres outils dans le test unit par exemple vous avez l'assert résiste qui vous permet de tester que l'exception est correctement résiste parce que c'est important aussi de tester que l'exception est correctement résiste mais aussi de fail de la manière dont vous espérez vous avez aussi l'assert warns et locs c'est quand vous mettez les warnings dans votre code donc comme ça vous devez être sûr que les warnings sont correctement displays et les locs c'est quand c'est pour tester que des locs sont générés d'asserts equals dix equals et d'autres vous avez plusieurs kinds d'asserts selon le type d'objet que vous êtes testé c'est vous donner un bon résultat quand c'est fail l'assert list equals vous montrer les éléments qui sont mismatchés qui sont dans l'un de l'autre et d'autres et il y a aussi un cleanup qui vous permet de régister des fonctions à s'arrêter à tirer dans le setup parce que parfois vous utilisez des informations dans les setups ce sera complètement oublié quand vous faites le tirer donc vous devez avoir cet environnement pour les restaurer nous utilisons pour exemple pour changer les valeurs de configuration au début du test et pour restaurer les valeurs initiales donc nous avons dans le setup les valeurs de configuration nous gardons dans le contexte du callback que l'ad cleanup va ajouter donc nous pouvons restaurer les valeurs correctes il y a un autre test quand vous avez testé votre partie du unité maintenant vous devez tester que le BF ou l'interacte correctement et c'est l'intégration test c'est de tester que toutes les parts ou les unités reste 10 minutes donc cela veut dire que vous ne devez pas tester certaines fonctions dans votre code mais plus l'application publique de votre application comme ça vous tricoterez l'interaction entre les compétences donc des bonnes pratiques bien sûr vous ne devez pas oublier l'interaction après le test parce que quand vous testez l'intégration vous devez prendre quelque part dans l'application donc bien sûr vous devez l'interaction et ces tests sont plus designés pour vérifier l'absence de l'erreur quand toutes les parts sont en train de rassembler plutôt qu'un résultat final si vous avez designé votre application vous devez savoir que chaque fonction est parce que vous avez un test en comportant comme ça donc c'est plus d'assurer que tout fonctionne ensemble et fonctionne bien ensemble donc c'est plus de tester qu'il n'y a pas d'erreur oui et dans Python la façon d'en faire c'est d'avoir dans Triton on a l'intégration test parce qu'on a des metodes et des metodes pour pour ces tests parce qu'on a un peu de choses qui seront utilisées pour tous les tests et bien sûr de les tirer donc le prochain type c'est le fonctionnel ici, quand vous faites un test fonctionnel vous devez tester l'application de l'application du point de vue de l'utilisateur donc par exemple, dans le cas de writing a ERP vous devez tester tout le workflow de un sale donc vous devez créer un sale dans votre application et vous devez créer des shipments qui vont créer la création de l'application et de l'application et donc vous devez tester tout le workflow pour juste un simple cas un simple sale mais vous devez assurer que tout est correctement interconnecté et que le sale crée correctement l'application et tout tout est travaillé et donc pour pouvoir faire un test fonctionnel et pour être sûr que c'est vraiment utile vous devez utiliser le stack de votre application ça veut dire que vous devez utiliser le database et pas de votre database vous devez utiliser le network si c'est connecté vous devez tester que l'accessoire correctement est appliqué et donc vous devez être sûr que l'utilise va avoir accès à tous les documents et le workflow et tout comme ça et pour ça le meilleur moyen c'est de simuler le comportement de l'utilise pour exemple vous devez utiliser des outils comme Selenium qui est un moyen de scripter pour cliquer sur le bouton et tout comme ça et vous devez juste contrôler comme si vous étiez un utilisateur ou d'autres manières si c'est dans notre cas votre application est déclinée si l'application est divisée dans plusieurs tiers vous pouvez juste faire l'application et c'est ce que nous faisons une libraire qui permet de faire facilement l'application pour la main server et donc nous avons tous les stacks et généralement la façon de faire un test fonctionnel c'est d'utiliser un test doc c'est un test dans Triton on va juste faire un ordre de sale avec des lines de sale et des quantités et à la fin on vérifie que l'amount est correctement correct et le workflow est ici on a des méthodes cliques qui simulent un clic sur les boutons et tout comme ça et vous avez aussi Selenium qui est sur le test de votre application web et c'est une libraire qui vous permet de manipuler d'aider un browser et ici vous avez le cas pour Firefox et comme on l'a dit vous avez initialement un setup et un tier down parce que vous avez besoin de setup et de préparer l'application pour faire le test et on va juste tester qu'il n'y ait pas d'erreur et aussi on teste juste des trucs basiques pour qu'il n'y ait pas de résultats mais on ne teste pas le tout l'HTML qui est généré on teste seulement une petite partie l'un qui est intéressant pour nous c'est parce que vous ne voulez pas rewrite ce test chaque fois que vous faites un petit change quelque part dans votre template oui un autre type de test c'est l'un généré comme on l'a déjà dit c'est pour tester les propriétés de l'output en utilisant l'input mais le random n'est pas complètement random vous définissez un scope dans lequel le système va choisir les valeurs ce type de test c'est pour essayer de mettre d'autres inputs donc le data random et essayer de break votre code c'est plus sur la sécurité oui, généralement c'est plus sur la sécurité et on trouve que ce n'est pas en code C mais en Python, bien sûr c'est intéressant aussi mais c'est moins généralement c'est un test génétique c'est bien de l'incluer dans votre intégration parfois c'est souvent parce qu'il y a beaucoup de cases mais aussi ce n'est pas reproductible comme on l'a dit c'est important de reproduire votre test en cas de failure et ici l'issue sera pour un comité peut-être que votre test va fail mais pas parce que le comité mais c'est un bug dans votre application et sur cet expérience le tool de génération va générer ce bug mais c'est juste d'une chance donc ce n'est pas une bonne idée de mixer les deux et faire des choses, les développeurs ont broken quelque chose d'une fois, c'était déjà broken depuis un long temps donc le test de génération va juste aller de temps à temps mais au-delà du comité c'est un exemple d'hypothèse on n'a jamais utilisé l'hypothèse mais c'est suffisant de faire ça vous pouvez voir que vous avez la définition d'input-values pour une hypothèse et vous définissez que la fonction publique et vous définissez la propriété que la fonction publique vous pouvez le suivre donc si vous étiez dans votre première année de sciences de computer vous pouvez vous rappeler que vous avez encore une variante pour vos loops et c'est de toute façon la variante de votre loop donc c'est assez intéressant et le dernier test c'est un test de performance c'est un test que vous allez tourner de temps à temps et essayer de measure la différence entre versions habituellement pour voir si votre code va plus vite ou moins plus vite vous devez être careful quand vous faites une mesure de la mesure de votre application donc il y a de l'application l'application de l'OS l'application de la database etc donc c'est très difficile d'avoir un résultat correct pour cela mais de toute façon c'est très difficile de comparer d'augmenter la performance et c'est aussi de plus en plus de choses parce que vous avez un customer qui tient oh mon Dieu ce report est en train de tourner et c'est le temps où vous faites votre test mais ce n'est pas quelque chose bien sûr, vous devriez penser à la performance mais c'est plus abstract et aussi vous pouvez tester la capacité de l'application si c'est une application network et vous faites ça de faire beaucoup de requests pour votre application donc pour measure le temps il y a des modules en Python qui vous donnent des tools parfaits pour cela mais il peut vous donner des ints sur la performance et pour la performance par exemple, il y a le boom library qui tient beaucoup de requests pour votre web site et qui fait des mesures et vous donnez un avantage etc donc en conclusion c'est plus sur comment on voit le test on pense qu'on devrait faire suffisamment de tests avec votre base code mais vous n'avez pas de faire trop de tests pour que ça vous bloque et vous protège pour l'évolver c'est une balance que vous devez trouver entre tous les tests entre les tests unis, l'intégration et le test de comportement dans une façon confidente que votre application fonctionne bien et que vous pouvez le faire évoluer avec la paix avec la paix de la paix any questions ? oui d'ailleurs on voit que dans Triton on write plus fonctionnel test et l'intégration test qu'un test unique on write un test unique pour le cours du framework mais en ce cas il n'y a pas trop de necesité d'injection on essaie de réduire la dépendance et oui mais parfois on moque ou on patch les modules permettent aussi de patcher des méthodes spécifiques d'objets donc vous pouvez limiter le scope de votre moque pas de questions pas de remarques sur le fait que nous devons faire un test ok merci et