Welkom terug.
Laten we een leuke kleine oefening doen door een stukje code dat we eerder hebben geschreven opnieuw te
bekijken. Denk aan het willekeurige spel zonder raden waarbij we een getal tussen één en tien moesten raden als ik dit bestand uitvoer, zie je
dat?
Het vroeg me te raden.
Dus laten we zeggen een, twee, drie, vier, vijf, zes, zeven, acht, negen.
En ik krijg eindelijk het nummer.
Jij bent een genie.
Het aantal was negen.
Dus hoe kunnen we deze code nu testen?
Een ding dat je hier zult opvallen, is dat we niet echt een functie hebben.
Ik herinner me dat ik je vertelde over functioneel programmeren en dat het goed is
om onze code op te splitsen in kleine stukjes functies die één ding heel goed doen, vooral pure functies.
Welnu, een van de grote voordelen van die mentaliteit is dat je code maakt die heel, heel gemakkelijk te testen
is.
In plaats van echt ingewikkelde logica in onze tests te hebben, kunnen we onze functies gewoon een
invoer geven en een uitvoer verwachten en daarom hebben we een eenheidstest.
En het idee van een eenheidstest is dat we elk stuk eenheid testen.
Deze unit tests zijn kleine stukjes die deze eenvoudige functies testen.
Dus mijn uitdaging aan jou is om deze code te gebruiken en te proberen dit op te splitsen in eenvoudige functies.
Nutsvoorzieningen.
In ons geval wil ik dat we alleen dit deel van de code testen, het gedeelte waar we een invoer
krijgen.
Dat is de gok en test het dan met een willekeurig antwoord dat we hebben en we zouden een soort van output
moeten verwachten.
Dus ofwel voeren we een nr.
Het moet één tot tien zijn, en als we het goed hebben, moeten we de string pakken.
Maar de sleutel hier is dat we dit waarschijnlijk willen verplaatsen naar een functie die we kunnen testen, we kunnen
de buitenwereld negeren.
En verdeel dit in zijn eigen kleine functie.
Dus pauzeer de video hier.
Geef het een kans.
Je zult door een aantal struikelblokken heen moeten komen, maar het zal je begrip van tests echt op de
proef stellen.
Hahaha.
Grappig, dat was een op.
Dus geef de video door, probeer het, anders ga ik aan de slag met het antwoord.
Het eerste dat ik wil doen, is mijn test opnieuw instellen, ik ga unit-test importeren en ik ga
de class test main maken.
Of laten we deze keer een testscript of testgame noemen.
Ik ga zeggen unit test dot test case.
Dit wordt onze testcase en dan zal ik hier, laten we zeggen, een simpele testtekst maken.
Spel- of testinvoer?
Ontvang het zelf.
En voor nu sla ik dit gewoon over omdat we niet echt iets doen.
Tot slot zal ik zeggen als.
Naam, want voor mij voer je dan de eenheidstest uit.
Punt hoofd.
Dit is dus slechts onze eenvoudige opstelling.
Dus als we dit nu uitvoeren, laten we zeggen Python drie.
Test door.
U ziet dat we één test hebben gedaan.
Oké, dus dit is onze volgende setup, wat ik wil doen is dit eruit halen, zodat ik het in mijn testbestand
kan gebruiken door het uit te pakken in een functie.
Dus ik ga het hier maar bovenaan zeggen.
Ik ga onze gok definiëren.
Gain of laten we het Ron noemen.
Gok.
Dat gaat input krijgen.
Of laten we zeggen een gok, en dan gaat het deze code uitvoeren, dus laten we dat doen.
Ik ga nemen.
Dit stukje code.
Soortgelijk.
En plak het hier gewoon in.
Nu zal de verkeerde gok ook de antwoordvariabele nodig hebben, dus ik ga het een tweede parameterantwoord
geven.
Zoals dit, zodat ik nu gewoon hier naar binnen kan.
Voer deze functie uit met de gasten en antwoord.
Gewoon zo.
Dus laten we het hier opslaan en deze test uitvoeren of laten we gewoon het eigenlijke bestand uitvoeren om er zeker van te zijn dat het nog steeds
werkt.
En we hebben daar een beetje een inspringing, dus we moeten ervoor zorgen dat onze inspringing correct is, want
onthoud in Python dat dat iets betekent.
Oké, nu hebben we een probleem, we hebben een pauze buiten de lus, want terwijl we de pauze
gebruiken, sleutelwoord en terwijl we ons op dit moment buiten een lus bevinden.
Dus een ding dat we kunnen doen, is dat we kunnen zeggen: kom hier terug.
Dus laten we dat nog eens herhalen.
En blijf een naam raden.
Of een nummer, en daar ga je.
Dit werkt nog steeds, ik kan hier return gebruiken omdat deze put gaat lopen en terugkeren, maar nu zitten we nog
steeds in het spel.
Dus misschien kunnen we gewoon terugkeren.
Waar.
En zeg, als.
Doe een gok.
Het is waar, we gaan hier uitbreken.
Nogmaals, laten we beginnen met ons spel.
Ik ga dit gewoon wissen en het spel opnieuw starten.
Een twee drie vier.
En daar ga je.
Ik heb een nee ingevoerd, ik ben een genie, we zijn net klaar met het spel.
Laten we dit een beetje kleiner maken, zodat je het kunt zien.
Dus we hebben onze gok dat ik de code een beetje heb aangepast.
Maar het belangrijkste is dat ik een functionaliteitseenheid eruit heb gehaald, zodat ik zoiets als 'run guess' kan
testen.
Het lijkt er dus op dat ik onze code heb aangepast, maar de code werkt nog steeds.
Dus laten we nu beginnen met het testen van onze meest foute functie.
Laten we hierheen gaan.
En begin met het importeren van ons script.
En hier, doe eerst een paar dingen, ik wil het antwoord op, laten we zeggen, gelijk aan vijf.
En de gok wordt gelijk aan vijf, dus we willen er zeker van zijn dat als de
gasten en het antwoord overeenkomen, nou ja, de verkeerde gasten gaan door het if-statement en printen uit, je bent een genie of in
ons geval, true retourneert .
Dus laten we zeggen autodidact beweren.
Gelijkwaardig.
Dat script of eigenlijk de eerste keer, laten we het daadwerkelijk uitvoeren, dus laten we een resultaat hebben dat gelijk is
aan script DOT.
Wat was er, Rodrguez?
Voer een gok uit en geef het antwoord en gok.
En we verwachten het resultaat.
Retourneer waar, dus we kunnen gewoon zeggen waar dat is.
Het resultaat is waar als ik dit nu uitvoer.
Oh, we starten het spel eigenlijk op, dus hoe kunnen we dit oplossen?
Welnu, we kunnen dit sluiten en de if-naam main toevoegen.
Hier.
Dus hier beneden.
We zullen zeggen, hey, voer dit alleen uit als dit het hoofdbestand is dat zomaar wordt uitgevoerd.
Als ik terug ga om hier te testen en dit opnieuw uit te voeren.
Oké, nu werkt het, maar ik krijg een bewering dat het spelobject van de luchttest geen attribuut heeft, beweert waar,
want, nou, ik.
Spel dat eens verkeerd.
Laten we dat nog eens proberen.
Oké, het lijkt erop dat er één test is uitgevoerd en dat alles goed is.
We zien ook dat je een genie bent, heel erg aardig.
Trouwens, ik laat je deze manier van testen zien, want zo ziet een realistisch scenario eruit.
Je blijft dingen breken, je blijft fouten maken, en dan probeer je ze te repareren en je code te
corrigeren.
En je kunt zien dat onze code er al steeds beter uitziet door deze tests uit te voeren.
Oké, wat kunnen we nog meer doen, laten we zeggen, hier?
Dat we dit gaan kopiëren en zodat de dingen korter zijn, ga ik de parameters hier
rechtstreeks invoeren.
Gewoon zo.
Laten we zeggen smaakinvoer, laten we zeggen onjuist.
Of.
Verkeerde gok.
Dus laten we zeggen dat het antwoord vijf is en ik denk nul.
Dus we willen beweren dat dit gelijk staat aan een false.
Dus als ik dit doe, slagen er twee tests, dat is geweldig.
Wat kunnen we hier nog meer testen?
Oké, nou, we willen testen of als de gok niet tussen nul en 10 of tussen één en 10 ligt, in dat geval,
we een afdruk willen hebben van, hé, bozo, ik zei één tot tien.
Dus ik kan weer testen.
Dat als mijn gok verkeerd.
Nee.
Laten we zeggen dat het antwoord vijf is, maar ik geef 11.
We willen beweren.
Welnu, op dit moment zijn we aan het afdrukken en doen we niets, dus misschien moeten we false retourneren om hier enige consistentie
te hebben.
Nogmaals, als ik dat doe en ik ren.
Daar ga je.
Drie tests zijn geslaagd, dat is geweldig, en er zijn nog veel, veel meer tests die we kunnen schrijven.
Laten we misschien nog een test doen, namelijk testen.
Wat als de invoer een string is?
Als ik dit uitvoer.
En zorg dat dat fout is.
Typ hier, zorg ervoor dat de namen verschillend zijn.
En ik heb vier tests lopen.
Want dit gaat niet door en het wordt false terug.
Er zijn nog veel meer dingen die we hier kunnen doen, maar je kunt nu de kracht van testen zien als je een
andere test hebt dan ik.
Dat is oké, allemaal.
Testgevallen zijn anders.
Het hele punt van testen is om gewoon te doen.
Kijk naar onze code en zie hoe we deze kunnen verbeteren, hoe we onze code kunnen breken, hoe we onze code
kunnen vereenvoudigen door hem op te splitsen in kleinere eenheden, kleinere eenheden die kunnen worden getest en enkele fouten oplossen die we misschien
niet hadden gedacht over.
Nu zijn er nog veel meer dingen die we kunnen doen.
Maar je merkt hier hoe het idee was om te werken aan kleine stukjes tegelijk getest.
En dan misschien verderop, kunnen we kijken naar dit deel van de code of misschien het proberen en accepteren deel van de
code.
En hier is het ding, als je voor een bedrijf werkt, ik beargumenteer dat er een oneindig aantal tests zijn die je
kunt doen.
Je kunt hier honderden regels hebben om je code in bits te testen.
Maar alleen omdat je zo vaak mogelijk test, maakt je tests nog niet echt goed.
Zoals ik al zei, er is een oneindig aantal tests die je kunt schrijven.
Het idee is om tests van goede kwaliteit te schrijven die de meeste van uw gevallen dekken, maar uiteindelijk zult u een afnemend rendement
hebben waarbij u een afweging moet maken tussen het schrijven van code en het schrijven van tests.
En soms, afhankelijk van wat de taak vereist, moet u zich misschien meer concentreren op tests en minder
op code.
Of soms moet je snel handelen en heb je geen tijd om tests te schrijven.
En nogmaals, afhankelijk van de zakelijke behoeften kan dat ook het geval zijn.
Maar met dit gedeelte hoop ik dat u enkele van de principes begrijpt die volgen op het testen in softwareontwikkeling.
Dat wil zeggen, er zullen altijd bugs in onze code voorkomen.
En we kunnen Lintang gebruiken om ons hierbij te helpen, maar een van de beste manieren om ervoor te zorgen dat onze
code goed werkt, is testen.
En hoe meer tests we meestal hebben, hoe stabieler onze code.
Ik zie wel in de volgende, doei.