Ben tornato.
Facciamo un piccolo esercizio divertente rivisitando un pezzo di codice che abbiamo scritto prima, ricordando
il gioco casuale senza indovinelli in cui dovevamo indovinare un numero compreso tra uno e dieci se eseguo questo file, lo vedi?
Mi ha chiesto di indovinare.
Quindi diciamo uno, due, tre, quattro, cinque, sei, sette, otto, nove.
E finalmente ho il numero.
Sei un genio.
Il numero era nove.
Quindi, come possiamo testare questo codice ora?
Una cosa che noterai qui è che in realtà non abbiamo una funzione.
Ricordo quando ti ho parlato della programmazione funzionale e di come sia utile suddividere il
nostro codice in piccoli frammenti di funzioni che fanno una cosa e una cosa davvero bene, specialmente funzioni pure.
Bene, uno dei grandi vantaggi di questa mentalità è che crei codice che è davvero, davvero facile da
testare.
Invece di avere una logica davvero complicata nei nostri test, possiamo semplicemente dare alle nostre funzioni un input
e aspettarci un output ed è per questo che abbiamo il test unitario.
E l'idea di un test unitario è che stiamo testando ogni pezzo di unità.
Questi test unitari sono piccoli pezzi che mettono alla prova queste semplici funzioni.
Quindi la mia sfida per te è usare questo codice e provare a suddividerlo in semplici funzioni.
Ora.
Nel nostro caso, voglio che testiamo solo questa parte del codice, che è la parte indovinata in cui riceviamo un
input.
Quale sarà l'ipotesi e quindi testala rispetto a una risposta casuale che abbiamo e dovremmo aspettarci una sorta
di output.
Quindi o inseriamo un n.
Deve essere da uno a 10, e se lo facciamo bene, dobbiamo ottenere la stringa.
Ma la chiave qui è che probabilmente vogliamo spostare questo in una funzione che possiamo testare, possiamo ignorare
il mondo esterno.
E scomponi questo nella sua piccola funzione.
Quindi metti in pausa il video qui.
Provaci.
Dovrai superare alcuni ostacoli, ma metterà davvero alla prova la tua comprensione dei
test.
ahah.
Divertente, era una cosa.
Quindi passa il video, provalo, altrimenti vado avanti con la risposta.
La prima cosa che voglio fare è impostare di nuovo il mio test, importerò unit test e creerò
il test di classe main.
Oppure chiamiamo uno script di prova questa volta o prova il gioco.
Sto per dire test case del punto di test dell'unità.
Questo sarà il nostro test case e poi qui creerò, diciamo, solo un semplice test.
Ingresso di gioco o di prova?
Ricevi il sé.
E per ora, lo passerò solo perché non stiamo facendo davvero nulla.
Infine, dirò se.
Nome, perché a me poi eseguo il test unitario.
Punto principale.
Quindi questa è solo la nostra semplice configurazione.
Quindi, se eseguiamo questo ora, diciamo Python tre.
Prova da.
Vedi che abbiamo eseguito un test.
Va bene, quindi questa è la nostra configurazione successiva, quello che voglio fare è effettivamente eliminarlo in modo da poterlo
utilizzare nel mio file di test estraendolo in una funzione.
Quindi dirò solo qui in alto.
Vado a definire la nostra ipotesi.
Guadagna o chiamiamolo Ron.
Indovina.
Riceverà un input.
O diciamo un'ipotesi, e poi eseguirà questo codice, quindi facciamolo.
vado a prendere.
Questo pezzo di codice.
Come questo.
E semplicemente incollalo qui.
Ora, anche l'ipotesi sbagliata avrà bisogno della variabile di risposta, quindi darò una seconda risposta di
parametro.
In questo modo, così ora posso semplicemente entrare qui dentro.
Esegui questa funzione con gli ospiti e rispondi.
Proprio così.
Quindi salviamolo qui ed eseguiamo questo test o eseguiamo semplicemente il file effettivo per assicurarci che funzioni ancora.
E abbiamo un po' di indentazione lì, quindi dobbiamo assicurarci che la nostra indentazione sia corretta perché
ricorda in Python, questo significa qualcosa.
Bene, ora abbiamo un problema, abbiamo un'interruzione al di fuori del ciclo perché mentre stiamo usando l'interruzione, la parola
chiave e mentre siamo al di fuori di un ciclo in questo momento.
Quindi una cosa che possiamo fare è dire di tornare qui.
Quindi eseguiamolo di nuovo.
E continua a indovinare un nome.
O un numero, ed ecco fatto.
Funziona ancora, posso usare il ritorno qui perché questo pozzo funzionerà e tornerà, ma ora siamo ancora
all'interno del gioco.
Quindi forse possiamo semplicemente tornare.
Vero.
E dire, se.
Esegui indovinare.
È vero, ne usciremo.
Di nuovo, iniziamo il nostro gioco.
Ho intenzione di cancellare questo ed eseguire di nuovo il gioco.
Uno due tre quattro.
Ed ecco fatto.
Ho inserito un no, sono un genio, abbiamo appena finito il gioco.
Facciamolo un po' più piccolo, così puoi vedere.
Quindi abbiamo la nostra ipotesi di esecuzione che ho modificato un po' il codice.
Ma la cosa fondamentale è che ho estratto un'unità di funzionalità in modo da poter testare qualcosa come run
guess.
Quindi sembra che io abbia modificato il nostro codice, ma il codice funziona ancora.
Quindi ora iniziamo a testare la nostra funzione più sbagliata.
Andiamo qui.
E inizia a importare il nostro script.
E qui dentro, prima fai alcune cose, voglio che la risposta sia, diciamo, uguale a cinque.
E l'ipotesi sarà uguale a cinque, quindi vogliamo assicurarci che se gli ospiti e la
risposta corrispondono che, beh, gli ospiti sbagliati passano attraverso l'istruzione if e stampano, sei un genio o nel nostro
caso, restituisce vero .
Quindi diciamo affermare da autodidatta.
Pari.
Quello script o in realtà la prima volta, eseguiamolo effettivamente, quindi abbiamo un risultato uguale allo
script DOT.
Cos'era, Rodrguez?
Esegui indovina e dagli la risposta e indovina.
E ci aspettiamo che il risultato lo faccia.
Return true, quindi possiamo semplicemente dire assert true that.
Il risultato è vero se ora eseguo questo.
Oh, in realtà avviamo il gioco, quindi come possiamo risolvere questo problema?
Bene, possiamo chiuderlo e aggiungere effettivamente il nome if main.
Qui.
Quindi quaggiù.
Diremo, ehi, eseguilo solo se questo è il file principale che viene eseguito in questo modo.
Se torno a testare qui e lo eseguo di nuovo.
Va bene, ora funziona, ma ricevo un'asserzione che l'oggetto del gioco test aereo non ha alcun attributo assert true
perché, beh, io.
Errori di ortografia.
Proviamo di nuovo.
Va bene, sembra che sia stato eseguito un test e che sia andato tutto bene.
Si vede anche che ha stampato che sei un genio, molto, molto simpatico.
A proposito, ti sto mostrando questo modo di testare perché è così che appare uno scenario di vita reale.
Continui a rompere le cose, continui a commettere errori e poi provi a risolverli e a correggere il tuo
codice.
E puoi vedere che il nostro codice sta già migliorando sempre di più semplicemente eseguendo questi test.
OK, cos'altro possiamo fare, diciamo, qui?
Che stiamo per copiare questo e solo così le cose sono più brevi, inserirò direttamente i
parametri qui.
Proprio così.
Diciamo input di gusto, diciamo errato.
O.
Ipotesi sbagliata.
Quindi diciamo che la risposta è cinque e immagino zero.
Quindi vogliamo affermare che questo sarà uguale a un falso.
Quindi, se eseguo questo, passano due test, è fantastico.
Cos'altro possiamo testare qui?
Bene, vogliamo verificare che se l'ipotesi non è tra zero e 10 o tra uno e 10, in quel caso, vogliamo
avere una stampa di, ehi, bozo, ho detto da uno a dieci.
Quindi, ancora una volta, posso provare.
Che se la mia ipotesi è sbagliata.
No.
Diciamo che la risposta è cinque, ma io do 11.
Vogliamo affermare.
Bene, in questo momento stiamo stampando e non stiamo facendo nulla, quindi forse dovremmo restituire false solo per avere un po' di
coerenza qui.
Di nuovo, se lo faccio e corro.
Ecco qua.
Tre test stanno superando, è fantastico, e ci sono molti, molti altri test che possiamo scrivere.
Forse facciamo un altro test, che è quello di testare.
E se l'input è una stringa?
Se eseguo questo.
E assicurati che sia sbagliato.
Digita qui, assicurati che i nomi siano diversi.
E ho quattro test in corso.
Perché questo non passerà e tornerà falso.
Ora, ci sono molte altre cose che possiamo fare qui, ma puoi vedere il potere del test proprio ora se hai un
test diverso dal mio.
Va bene, tutti quanti.
I casi di test sono diversi.
L'intero punto del test è semplicemente.
Guarda il nostro codice e vedi come possiamo migliorarlo, come possiamo rompere il nostro codice, come possiamo semplificare
il nostro codice suddividendolo in unità più piccole, unità più piccole che possono essere testate e correggere alcuni errori che forse
non avremmo pensato di.
Ora, ci sono molte altre cose che possiamo fare.
Ma qui si nota come l'idea fosse quella di lavorare su un pezzo piccolo alla volta testato.
E poi forse più avanti, possiamo guardare questa parte del codice o forse provare ad accettare una parte del
codice.
Ed ecco il punto, quando lavori per un'azienda, sostengo che ci sono un numero infinito di test che
puoi fare.
Puoi avere centinaia di righe qui per testare il tuo codice a bit.
Ma solo perché stai testando il maggior numero di volte possibile non rende i tuoi test davvero buoni.
Come ho detto, c'è un numero infinito di test che puoi scrivere.
L'idea è di scrivere test di buona qualità che coprano la maggior parte dei tuoi casi, ma alla fine avrai
rendimenti decrescenti in cui devi avere un compromesso tra scrivere codice e scrivere test.
E a volte, a seconda di cosa richiede il lavoro, potresti doverti concentrare di più sui test e meno
sul codice.
O a volte forse hai bisogno di muoverti velocemente e non hai tempo per scrivere i test.
E ancora, a seconda delle esigenze aziendali, potrebbe essere anche così.
Ma con questa sezione, spero che tu capisca alcuni dei principi che seguono i test nello sviluppo del software.
Cioè, i bug si presenteranno sempre nel nostro codice.
E possiamo usare Lintang per aiutarci in questo, ma uno dei modi migliori per assicurarci che il nostro codice
funzioni correttamente è il test.
E più test che abbiamo di solito significa, più stabile è il nostro codice.
Vedrò nel prossimo, ciao ciao.