Content de te revoir.
Continuons avec nos tests unitaires maintenant.
Une chose que j'ai remarquée ici est que lorsque nous examinons la documentation, nous avons en fait un insert est instance.
Donc, nous pouvons en fait, au lieu de dire Asatru, simplement utiliser, l'assertion est une instance, que nous donnons à nouveau à A
et B, toutes ces méthodes de test, il n'y en a pas de bonne.
Vous pouvez utiliser celui que vous voulez comme outil pour améliorer votre code.
Donc, dans mon cas, changeons simplement cela pour affirmer son instance et corrigeons cela.
Comme ça, donc juste un peu plus propre, voyons si cela fonctionne, d'accord.
Tout est encore bon.
OK, essayons à nouveau de casser notre code.
Donc tout se présente bien.
Mais et si nous faisions quelque chose de différent ?
Et si nous le faisions, disons, à un autre test et que nous dirions aussi tester faire des trucs ?
En général, vous voulez mieux nommer ces fonctions.
Ils sont donc plus descriptifs.
Mais dans notre cas, tout va bien.
Juste pour que nous puissions voir comment ils fonctionnent cette fois-ci.
Faisons le test param va être égal.
Que diriez-vous d'un aucun?
Alors maintenant, si j'exécute ceci, exécutons à nouveau ce code.
Et au fait, vous remarquerez peut-être ici comment je copie du code dans un test et vous pourriez penser, eh bien,
pouvons-nous simplement simplifier les choses ?
Et ne pas nous répéter.
Et vous pouvez totalement le faire et rendre les choses beaucoup plus faciles.
Mais quand il s'agit de tests, parce qu'ils ne sont pas mis en production et c'est uniquement
à des fins de développement, vous voulez vraiment avoir des tests faciles à lire pour que d'autres personnes comprennent
vos tests, car quand il s'agit de tests, la lisibilité est vraiment, vraiment important.
Nous ne nous soucions pas autant de ne pas nous répéter et de rendre notre code efficace, agréable et petit.
J'aime donc écrire des tests qui soient vraiment descriptifs, vraiment évidents.
D'accord, ici, disons que les autodidactes affirment l'égalité et hmm, qu'est-ce que cela devrait être ?
Eh bien, dans ce cas, je m'attends à une erreur de valeur, alors faisons-le.
Je m'attends à ce que le résultat soit une valeur er je vais enregistrer et exécuter mon test.
Très bien, j'obtiens une erreur, cela dit qu'il s'agit d'une erreur de type dans l'argument, doit être une chaîne.
Et je lui donne un non type.
Très bien, donc cela ne le gère pas correctement car cela ne fonctionne tout simplement pas avec l'ENT, nous obtenons une
erreur de type.
Alors, comment pouvons-nous résoudre ce problème ?
Huckabee l'ajuste au cas où nous obtenons un non-type dans le paramètre.
Eh bien, tout d'abord, donnons-lui un paramètre par défaut, disons que le paramètre par défaut est zéro si je
l'exécute.
Encore.
J'ai toujours l'air.
OK, donc nous ne l'avons toujours pas corrigé.
L'argument doit être un strict.
Un objet similaire à acheter ou un type non ?
OK, donc nous ne vérifions toujours pas le type de nounou.
Donc, une autre chose que nous pouvons faire est de dire.
Si.
Non.
Nous vérifions donc si nous avons la valeur numérique.
Parce que rappelez-vous, cela va être vrai par défaut s'il a n'importe quelle sorte de nombres ou, enfin, n'importe quelle valeur, mais s'il
ne s'agit pas d'un type, il deviendra en vigueur.
Donc ici, si non, nous pouvons dire retourner ceci.
Sinon, sinon, nous reviendrons.
S'il te plaît.
Entrer un nombre.
Je vais donc dire ceci et maintenant changer cela, car maintenant nous devrions nous attendre à ce que le nombre soit entré
dans mon test et je vais dire affirmer égal.
Ce résultat.
Sera s'il vous plaît entrez Non.
Si j'étais maintenant sur mon test, clarifions cela.
Oh, on dirait que je fais deux tests en zéro seconde, mais nous avons trois tests, et c'est parce que.
Vous voyez ici que j'ai nommé le mien de la même manière.
N'oubliez pas que si vous nommez la chose de la même manière, eh bien, elle n'en exécutera qu'une.
Assurez-vous donc que tous les noms de test sont uniques.
Je vais donc lancer ça.
Très bien, j'ai effectué trois tests et tout fonctionne bien.
Très cool.
Vous pouvez donc voir ici comment nous sommes passés d'une fonction très simple et nous avons commencé
à détecter ces erreurs et à réaliser à quel point notre fonction était trop simpliste, que si nous recevions une mauvaise entrée.
Comme.
Une chaîne ou un non type ?
Eh bien, dès que nous avons fait cela, notre fonction a échoué.
Donc, en utilisant des tests et en testant et cassant des choses, j'ai pu améliorer cette fonction.
Il est donc plus durable, de sorte qu'il fonctionne maintenant beaucoup mieux en production.
À droite.
Et c'est le pouvoir des tests.
Cela nous permet de vérifier les erreurs que nous avons pu commettre, car nous n'aurions peut-être pas pensé à faire
quelque chose comme ça au départ.
Mais en écrivant des tests à côté de notre code, nous avons pu améliorer la fonction.
Maintenant, une dernière chose que je veux ajouter.
Ajoutons simplement un autre des tests et disons que cela fait quelque chose si le paramètre de test n'est
qu'une chaîne vide?
Nous devrions arriver à saisir un numéro, donc si je l'ai exécuté.
D'accord, quatre tests sont en cours de réussite, il semble donc que notre code fonctionne correctement.
Maintenant, pour terminer ici, je veux juste souligner quelques points.
J'appelle ici un test unitaire sur le Maine, mais cela n'a rien à voir avec le réel.
Déposer.
Ce que nous avons écrit, qui est le fichier principal, si disons que je le renomme, alors allons sur mon bureau.
Et dites, je veux changer cela en.
Scénario, DCPI.
Ouvrons maintenant ceci, mon cas avec un texte sublime.
Revenons ici.
Donc, vous voyez ici que cela signifie que PI est bien n'existe plus.
Il me demande d'économiser.
Il s'agit donc d'un fichier complètement différent.
Maintenant, si je fais un script ici et que je change simplement toutes les instances en script.
Si je sauvegarde ceci et que je cours maintenant.
Cela fonctionne toujours, le test unitaire signifie simplement, hé, exécutez simplement tous les tests ici.
Maintenant, une chose, et c'est une pratique courante dont nous avons déjà parlé, c'est parce que vous voulez
dire exécuter cet automne s'il s'agit du fichier principal en cours d'exécution, car nous ne voulons pas vraiment importer Tessmann ou quelque
chose comme ceci dans d'autres fichiers.
Ce sont des fichiers individuels qui ne doivent être exécutés que lorsque nous exécutons nos tests.
Je peux donc simplement dire si le soulignement souligne le nom.
Équivaut à.
Soulignement, trait de soulignement, principal.
Ensuite, exécutez ce morceau de code.
Alors maintenant, si je sauvegarde ceci et que je cours.
Voilà.
Tout fonctionne toujours, mais maintenant je m'assure qu'il s'agit d'un fichier de test et je ne vais exécuter ce code que
si c'est le fichier en cours d'exécution, si c'est le fichier principal en cours d'exécution.
Il s'agit donc d'une méthode standard pour effectuer votre test avec le module de test unitaire.
Faisons une pause et parlons un peu plus des tests dans la prochaine vidéo.