Altre risposte spiegano cosa è beffardo. Lascia che ti accompagni attraverso diversi esempi . E credimi, in realtà è molto più semplice di quanto pensi.
tl; dr È un'istanza della classe originale. Ha altri dati iniettati in modo da evitare di testare le parti iniettate e concentrarsi esclusivamente sul test dei dettagli di implementazione della classe / funzioni.
Un semplice esempio:
class Foo {
func add (num1: Int, num2: Int) -> Int { // Line A
return num1 + num2 // Line B
}
}
let unit = Foo() // unit under test
assertEqual(unit.add(1,5),6)
Come puoi vedere, non sto testando LineA, cioè non sto convalidando i parametri di input. Non sto convalidando per vedere se num1, num2 sono numeri interi. Non ho affermazioni contrarie.
Sto solo testando per vedere se LineB (la mia implementazione ) ha dato i valori derisi 1e 5sta facendo come mi aspetto.
Ovviamente nella parola reale questo può diventare molto più complesso. I parametri possono essere un oggetto personalizzato come Persona, Indirizzo, oppure i dettagli dell'implementazione possono essere più di un singolo +. Ma la logica dei test sarebbe la stessa.
Esempio non codificante:
Supponiamo che tu stia costruendo una macchina che identifica il tipo e la marca dei dispositivi elettronici per la sicurezza di un aeroporto. La macchina lo fa elaborando ciò che vede con la sua fotocamera.
Ora il tuo manager entra dalla porta e ti chiede di testarlo.
Quindi come sviluppatore puoi portare 1000 oggetti reali, come un MacBook Pro, Google Nexus, una banana, un iPad ecc. Di fronte a esso e testare e vedere se tutto funziona.
Ma puoi anche usare oggetti derisi , come un MacBook pro identico (senza parti interne reali) o una banana di plastica di fronte. Puoi salvarti dall'investire in 1000 laptop reali e banane in decomposizione.
Il punto è che non stai cercando di provare se la banana è falsa o no. Né test se il laptop è falso o meno. Tutto quello che stai facendo sta testando se la vostra macchina una volta che vede una banana direbbe not an electronic devicee per un MacBook Pro direbbe: Laptop, Apple. Per la macchina, il risultato del suo rilevamento dovrebbe essere lo stesso per l'elettronica falsa / beffarda e l'elettronica reale
La logica sopra menzionata si applica anche ai test unitari del codice reale. Questa è una funzione che dovrebbe funzionare allo stesso modo con valori reali ottenuti da input (e interazioni) reali o derisivalori iniettati durante il test unitario. E proprio come ti salvi dall'uso di una vera banana o MacBook, con unit test (e derisione) ti risparmi di dover fare qualcosa che induca il tuo server a restituire un codice di stato di 500, 403, 200, ecc. (Forzando il tuo server per attivare 500 è solo quando il server è spento, mentre 200 è quando il server è attivo. È difficile eseguire 100 test incentrati sulla rete se devi attendere costantemente 10 secondi tra il passaggio del server su e giù). Quindi invece si inietta / deride una risposta con il codice di stato 500, 200, 403, ecc. E si verifica l'unità / funzione con un valore iniettato / deriso.
Esempio di codifica:
Supponiamo che tu stia scrivendo un'applicazione iOS e che tu abbia chiamate di rete. Il tuo compito è testare la tua applicazione. Testare / identificare se le chiamate di rete funzionano o meno come previsto NON È LA TUA RESPONSABILITÀ. È responsabilità di un'altra parte (team server) testarlo. È necessario rimuovere questa dipendenza (di rete) e tuttavia continuare a testare tutto il codice che lo circonda .
Una chiamata di rete può restituire diversi codici di stato 404, 500, 200, 303, ecc. Con una risposta JSON.
La tua app dovrebbe funzionare per tutti (in caso di errori, l'app dovrebbe generare l'errore previsto). Quello che fai con il beffardo è creare risposte di rete "immaginarie - simili alle reali" (come un codice 200 con un file JSON) e testare il tuo codice senza "effettuare la chiamata di rete reale e attendere la risposta della tua rete". È possibile codificare / restituire manualmente la risposta di rete per TUTTI i tipi di risposte di rete e vedere se l'app funziona come previsto. ( non assumerai mai / testerai un 200 con dati errati, perché non è tua responsabilità, la tua responsabilità è testare la tua app con un 200 corretto o, nel caso di un 400, 500, testare se l'app genera l'errore giusto)
Questo immaginario creativo, simile al reale, è noto come beffardo.
Per fare ciò, non puoi usare il tuo codice originale (il tuo codice originale non ha le risposte pre-inserite, giusto?). È necessario aggiungere qualcosa ad esso, iniettare / inserto che i dati fittizi che non è normalmente necessaria (o una parte della vostra classe).
Quindi crei un'istanza della classe originale e aggiungi qualunque cosa (qui essendo la risposta HTTP di rete, i dati O in caso di errore, passi la stringa di errore corretta, risposta HTTP) di cui hai bisogno e quindi testa la classe derisa .
Per farla breve, beffardo è semplificare e limitare ciò che stai testando e anche farti nutrire da cosa dipende una classe. In questo esempio si evita di testare la rete si chiama , e invece di prova se la vostra applicazione funziona come ci si aspetta con le uscite / risposte iniettate - dal beffardo classi
Inutile dire che si testa ogni risposta di rete separatamente.
Ora una domanda che ho sempre avuto in mente era: i contratti / punti finali e sostanzialmente la risposta JSON delle mie API vengono costantemente aggiornati. Come posso scrivere unit test che tengano conto di ciò?
Per approfondire questo: diciamo che il modello richiede una chiave / campo chiamato username. Si verifica questo e il test passa. 2 settimane dopo il backend modifica il nome della chiave in id. I tuoi test ancora superano. destra? o no?
È responsabilità dello sviluppatore back-end aggiornare le beffe. Dovrebbe essere parte del nostro accordo che forniscono derisioni aggiornate?
La risposta al problema di cui sopra è che: unit test + il processo di sviluppo come sviluppatore lato client dovrebbe / verrebbe rilevato una risposta derisa obsoleta. Se mi chiedi come? bene la risposta è:
La nostra app attuale fallirebbe (o non fallirebbe ancora non avere il comportamento desiderato) senza usare le API aggiornate ... quindi se ciò fallisce ... faremo modifiche sul nostro codice di sviluppo. Il che porta di nuovo al fallimento dei nostri test .... che dovremo correggere. (In realtà se dobbiamo eseguire correttamente il processo TDD non dobbiamo scrivere alcun codice sul campo a meno che non scriviamo il test per esso ... e vederlo fallire e poi andare a scrivere il codice di sviluppo effettivo per esso.)
Tutto ciò significa che il backend non deve dire: "hey abbiamo aggiornato i mock" ... alla fine succede attraverso lo sviluppo / debug del tuo codice. ّ Perché fa tutto parte del processo di sviluppo! Anche se il backend fornisce la risposta derisa per te, allora è più facile.
Il mio punto su questo è che (se non puoi automatizzare ottenere una risposta API derisa aggiornata allora) sono richieste alcune interazioni umane, ad esempio aggiornamenti manuali di JSON e riunioni brevi per assicurarsi che i loro valori siano aggiornati diventeranno parte del tuo processo
Questa sezione è stata scritta grazie a una discussione lenta nel nostro gruppo Meetup CocoaHead
Solo per sviluppatori iOS:
Un ottimo esempio di derisione è questo discorso orientato al protocollo pratico di Natasha Muraschev . Passa al minuto 18:30, anche se le diapositive potrebbero non essere sincronizzate con il video reale 🤷♂️
Mi piace molto questa parte della trascrizione:
Perché questo sta testando ... vogliamo assicurarci che venga chiamata la getfunzione da Gettable, perché può tornare e la funzione potrebbe teoricamente assegnare una serie di prodotti alimentari da qualsiasi luogo . Dobbiamo assicurarci che sia chiamato;