Content de te revoir.
Faisons un petit exercice amusant en revisitant un morceau de code que nous avons écrit auparavant,
souvenez-vous du jeu aléatoire sans deviner où nous devions deviner un nombre entre un et dix si je lance ce fichier, vous voyez
ça?
Il m'a demandé de deviner.
Alors disons un, deux, trois, quatre, cinq, six, sept, huit, neuf.
Et j'obtiens enfin le numéro.
Tu es un génie.
Le nombre était neuf.
Alors comment pouvons-nous tester ce code maintenant ?
Une chose que vous remarquerez ici est que nous n'avons pas vraiment de fonction.
Je me souviens quand je vous ai parlé de la programmation fonctionnelle et de la façon dont il est bon
de diviser notre code en petits morceaux de fonctions qui font une chose et une chose très bien, en particulier des fonctions pures.
Eh bien, l'un des grands avantages de cette mentalité est que vous créez un code qui est vraiment, vraiment facile à
tester.
Au lieu d'avoir une logique vraiment compliquée dans nos tests, nous pouvons simplement donner à nos fonctions une
entrée et attendre une sortie et c'est pourquoi nous avons un test unitaire.
Et l'idée d'un test unitaire est que nous testons chaque élément unitaire.
Ces tests unitaires sont de petits morceaux testant ces fonctions simples.
Donc, mon défi pour vous est d'utiliser ce code et d'essayer de le diviser en fonctions simples.
À présent.
Dans notre cas, je veux que nous testions simplement cette partie du code, qui est la partie devinette où nous recevons
une entrée.
Ce qui sera la supposition, puis la tester par rapport à une réponse aléatoire que nous avons et nous devrions nous attendre à une sorte
de sortie.
Donc soit on rentre un Non.
Il doit être de 1 à 10, et si nous réussissons, nous devons obtenir la chaîne.
Mais la clé ici est que nous voulons probablement déplacer cela dans une fonction que nous pouvons tester, nous pouvons ignorer
le monde extérieur.
Et divisez cela en sa propre petite fonction.
Alors mettez la vidéo en pause ici.
Essayez.
Vous allez devoir surmonter quelques écueils, mais cela va vraiment tester votre compréhension des
tests.
Haha.
C'était drôle, c'était un moment.
Alors passez la vidéo, lancez-vous, sinon je vais me lancer avec la réponse.
La première chose que je veux faire est de paramétrer à nouveau mon test, je vais importer le test unitaire et je
vais créer la classe test main.
Ou appelons un script de test cette fois ou un jeu de test.
Je vais dire cas de test de point de test unitaire.
Cela va être notre cas de test et puis ici je vais créer, disons, juste un simple test disons.
Entrée de jeu ou de test ?
Recevoir le soi.
Et pour l'instant, je vais juste passer ceci parce que nous ne faisons vraiment rien.
Enfin, je dirai si.
Nom, car pour moi alors lancez le test unitaire.
Point principal.
C'est donc juste notre configuration simple.
Donc, si nous l'exécutons maintenant, disons Python trois.
Testez par.
Vous voyez que nous avons effectué un test.
Très bien, c'est donc notre configuration suivante, ce que je veux faire est de retirer cela afin que je puisse l'utiliser
dans mon fichier de test en l'extrayant dans une fonction.
Donc je vais juste dire en haut ici.
Je vais définir notre supposition.
Gagnez ou appelons ça Ron.
Devine.
Cela va recevoir une entrée.
Ou disons une supposition, puis il exécutera ce code, alors faisons-le.
Je vais prendre.
Ce morceau de code.
Comme ça.
Et collez-le simplement ici.
Maintenant, la mauvaise supposition aura également besoin de la variable de réponse, je vais donc lui donner une deuxième réponse de
paramètre.
Comme ça, pour que maintenant je puisse simplement à l'intérieur d'ici.
Exécutez cette fonction avec les invités et répondez.
Juste comme ça.
Enregistrons-le ici et exécutons ce test ou exécutons simplement le fichier réel pour nous assurer qu'il fonctionne toujours.
Et nous avons un peu d'indentation là-bas, nous devons donc nous assurer que notre indentation est correcte car rappelez-vous
en Python, cela signifie quelque chose.
Très bien, maintenant nous avons un problème, nous avons une pause en dehors de la boucle parce que pendant que nous utilisons la
pause, le mot clé et pendant que nous sommes en dehors d'une boucle en ce moment.
Donc, une chose que nous pouvons faire, c'est dire de revenir ici.
Alors reprenons ça.
Et continuez à deviner un nom.
Ou un numéro, et voilà.
Cela fonctionne toujours, je peux utiliser return ici parce que ce puits va fonctionner et revenir, mais maintenant nous sommes toujours
à l'intérieur du jeu.
Alors peut-être que nous pouvons simplement revenir.
Vrai.
Et dites, si.
Exécutez deviner.
C'est vrai, on va s'en sortir.
Encore une fois, commençons notre jeu.
Je vais juste effacer cela et relancer le jeu.
Un deux trois quatre.
Et voilà.
J'ai entré un non, je suis un génie, nous venons de finir le jeu.
Faisons cela un peu plus petit, juste pour que vous puissiez voir.
Nous avons donc notre course, je suppose que j'ai un peu modifié le code.
Mais l'essentiel est que j'ai extrait une unité de fonctionnalité afin que je puisse tester quelque chose comme run
guess.
Il semble donc que j'ai modifié notre code, mais le code fonctionne toujours.
Alors maintenant, commençons à tester notre fonction la plus erronée.
Allons ici.
Et commencez à importer notre script.
Et ici, faites quelques choses d'abord, je veux que la réponse soit, disons, égale à cinq.
Et la supposition sera égale à cinq, nous voulons donc nous assurer que si les invités et
la réponse correspondent, eh bien, les mauvais invités parcourent la déclaration if et s'impriment, vous êtes un génie ou dans notre
cas, renvoie vrai .
Alors disons autodidacte s'affirmer.
Égal.
Ce script ou en fait la première fois, exécutons-le, donc ayons un résultat égal au
script DOT.
Qu'est-ce que c'était, Rodrguez ?
Exécutez deviner et donnez-lui la réponse et devinez.
Et on attend le résultat.
Renvoie vrai, nous pouvons donc simplement dire affirmer vrai cela.
Le résultat est vrai si je lance maintenant ceci.
Oh, en fait, nous démarrons le jeu, alors comment pouvons-nous résoudre ce problème ?
Eh bien, nous pouvons fermer ceci et ajouter le nom if main.
Ici.
Alors ici en bas.
Nous dirons, hé, n'exécutez ceci que s'il s'agit du fichier principal exécuté comme cela.
Si je reviens pour tester ici et que je l'exécute à nouveau.
Très bien, maintenant cela fonctionne, mais j'obtiens un objet de jeu de test aérien d'assertion n'a pas d'attribut assert true parce que,
eh bien, je.
Épeler ça.
Essayons encore.
D'accord, on dirait qu'un test a été exécuté et que tout va bien.
On voit aussi que c'est imprimé tu es un génie, très, très gentil.
Au fait, je vous montre cette façon de tester parce que c'est à quoi ressemble un scénario de la vie réelle.
Vous continuez à casser des choses, vous continuez à faire des erreurs, puis vous essayez de les réparer et de corriger votre
code.
Et vous pouvez voir que notre code est déjà de mieux en mieux simplement en exécutant ces tests.
OK, que pouvons-nous faire d'autre, disons, ici ?
Que nous allons copier ceci et juste pour que les choses soient plus courtes, je vais juste entrer directement
les paramètres ici.
Juste comme ça.
Disons le goût d'entrée, disons incorrect.
Ou.
Mauvaise supposition.
Alors disons que la réponse est cinq et je suppose que zéro.
Nous voulons donc affirmer que cela va équivaloir à un faux.
Donc, si je lance ceci, deux tests réussissent, c'est génial.
Que pouvons-nous tester d'autre ici ?
D'accord, eh bien, nous voulons tester que si la supposition n'est pas entre zéro et 10 ou entre un et 10, dans ce cas,
nous voulons avoir une empreinte de, hé, bozo, j'ai dit un à dix.
Donc encore une fois, je peux tester.
Que si ma conjecture mal.
Non.
Disons que la réponse est cinq, mais je donne 11.
Nous voulons affirmer.
Eh bien, en ce moment, nous imprimons et ne faisons rien, alors peut-être devrions-nous retourner false juste pour avoir une certaine
cohérence ici.
Encore une fois, si je fais ça et je cours.
Voilà.
Trois tests réussissent, c'est super, et il y a beaucoup, beaucoup plus de tests que nous pouvons écrire.
Faisons peut-être un autre test, qui est de tester.
Et si l'entrée est une chaîne ?
Si je lance ça.
Et assurez-vous que c'est faux.
Tapez ici, assurez-vous que les noms sont différents.
Et j'ai quatre tests en cours.
Parce que ça ne va pas passer et ça va retourner faux.
Maintenant, il y a beaucoup plus de choses que nous pouvons faire ici, mais vous pouvez voir la puissance du test dès maintenant si vous avez
un test différent du mien.
C'est bon, tout le monde.
Les cas de test sont différents.
Le but du test est tout simplement.
Regardez notre code et voyez comment nous pouvons l'améliorer, comment nous pouvons casser notre code, comment nous pouvons simplifier notre
code en le divisant en unités plus petites, des unités plus petites qui peuvent être testées et corriger certaines erreurs auxquelles nous n'aurions
peut-être pas pensé sur.
Maintenant, il y a beaucoup plus de choses que nous pouvons faire.
Mais vous remarquez ici à quel point l'idée était de travailler sur des petites pièces à la fois éprouvées.
Et puis peut-être plus loin, nous pouvons regarder cette partie du code ou peut-être essayer et accepter une partie du
code.
Et voici le truc, quand vous travaillez pour une entreprise, je prétends qu'il y a un nombre infini de tests que vous
pouvez faire.
Vous pouvez avoir des centaines de lignes ici pour tester votre code en bits.
Mais ce n'est pas parce que vous testez autant de fois que possible que vos tests sont vraiment bons.
Comme je l'ai dit, il y a un nombre infini de tests que vous pouvez écrire.
L'idée est d'écrire des tests de bonne qualité qui couvrent la plupart de vos cas, mais vous finirez par avoir des
rendements décroissants où vous devrez faire un compromis entre l'écriture de code et l'écriture de tests.
Et parfois, selon les besoins du travail, vous devrez peut-être vous concentrer davantage sur les tests et moins sur
le code.
Ou parfois, vous avez peut-être besoin d'aller vite et vous n'avez pas le temps d'écrire des tests.
Et encore une fois, selon les besoins de l'entreprise, cela pourrait aussi être le cas.
Mais avec cette section, j'espère que vous comprenez certains des principes qui suivent les tests dans le développement de logiciels.
C'est-à-dire que des bogues vont toujours survenir dans notre code.
Et nous pouvons utiliser Lintang pour nous aider, mais l'un des meilleurs moyens de nous assurer que notre code
fonctionne correctement est de tester.
Et plus nous avons de tests moyens, plus notre code est stable.
Je verrai dans le prochain, bye bye.