Share
Sei nuovo di Rails? Nuovo nella codifica? Sei curioso di sapere su RSpec e come puoi iniziare a testare? Se è così, questo articolo dovrebbe essere un buon punto di partenza per entrare nello sviluppo basato sui test. Ti spiegherà il perché e il come, e ti fornirà un kit di sopravvivenza per iniziare la tua prima serie di test.
A cosa serve RSpec? RSpec è molto utile a livello di Test unità, testando i dettagli più fini e la logica di business della tua app. Ciò significa testare i componenti interni come i modelli e i controller della tua app. I test che coprono le tue visualizzazioni oi test di funzionalità che simulano flussi di utenti più completi, come l'acquisto di un articolo, non saranno il fulcro per cui RSpec è fatto. RSpec non utilizza un driver web, come Capybara, ad esempio, che simula le interazioni dell'utente con un sito reale o una rappresentazione di esso.
Sviluppo guidato dai test (TDD), qual è il punto? Bene, non è così facile rispondere senza nutrirti di cliché. Spero che questo non suoni evasivo. Potrei fornire una risposta rapida, ma voglio evitare di mandarti a casa affamato dopo aver mangiato solo un piccolo spuntino. Il risultato di questa piccola serie su RSpec e test non dovrebbe solo darti tutte le informazioni per rispondere da solo a questa domanda, ma fornirti anche i mezzi e la comprensione per iniziare a test, sentendoti già un po 'fiducioso riguardo alla prova.
I principianti sembrano avere più difficoltà a entrare in RSpec e nel flusso di lavoro TDD piuttosto che iniziare a diventare pericoloso con Ruby o Rails. Perché? Posso solo supporre a questo punto, ma da un lato, la letteratura sembra focalizzata principalmente su persone che hanno già alcune abilità di programmazione, e dall'altro lato, l'apprendimento di tutte le cose che sono coinvolte per avere una chiara comprensione è un po 'scoraggiante. La curva di apprendimento può essere piuttosto ripida, suppongo. Per test efficaci, sono coinvolte molte parti mobili. È molto chiedere ai neofiti che hanno appena iniziato a capire un framework come Rails per osservare il processo di creazione di un'app dalla prospettiva opposta e imparare una API completamente nuova per scrivere codice per il tuo codice.
Ho pensato a come affrontare questo "dilemma" per la prossima generazione di programmatori che stanno solo cercando un inizio più fluido in questa cosa. Questo è quello che mi è venuto in mente. Interromperò la sintassi più essenziale per te senza assumere molto più della semplice conoscenza di Ruby e un po 'di Rails. Invece di coprire ogni angolazione possibile e confonderti fino alla morte, esamineremo il tuo kit di sopravvivenza di base e cercheremo di dipingere il quadro più ampio. Discuteremo il "come?" Piuttosto verbalmente per non perdere nuovi programmatori lungo la strada. La seconda parte dell'equazione spiegherà il "Perché?"
Se sono fortunato, riuscirai a ottenere una buona base per libri più avanzati e ti sentirai sicuro del quadro più ampio. Ok ora, facciamo la passeggiata!
Torniamo allo scopo di testare. Il test è utile per scrivere app di qualità migliore? Beh, questo può essere molto dibattuto, ma al momento risponderei a questa domanda con un si-I'm nel campo del TDD a vita bassa, immagino. Vediamo perché i test forniscono alle tue app un paio di vantaggi difficili da ignorare:
Controllano se il tuo lavoro funziona come previsto. Convalidare costantemente che stai scrivendo il codice che funziona è essenziale per la salute della tua applicazione e per la sanità del tuo team.
Mettono alla prova cose che non vuoi testare a mano, controlli noiosi che potresti fare a mano, specialmente quando avresti bisogno di controllare tutto questo tempo. Vuoi essere il più sicuro possibile che la tua nuova funzione o la tua nuova classe o qualsiasi altra cosa non causi effetti collaterali in aree completamente impreviste della tua app. Automatizzare quel genere di cose non solo ti salva tonnellata di tempo ma renderà anche gli scenari di test coerenti e riproducibili. Questo li rende molto più affidabili dei test soggetti a errori a mano.
Vogliamo assicurarci che l'app si comporti in un certo modo, in modo atteso. I test possono garantire che il modo in cui gli utenti interagiscono con la tua app funzioni ed eviti gli scenari di bug che sei stato in grado di prevedere. I test verificano che l'applicazione funzioni come l'hai progettata e continua a funzionare dopo aver apportato le modifiche. Ciò è particolarmente importante quando la tua suite di test ti informa sugli scenari non riusciti relativi alle implementazioni della tua app che potrebbero essere obsolete e quindi non esattamente nella parte posteriore del tuo cervello e non prese in considerazione mentre introducevi nuove funzionalità. In breve, aiuta a mantenere la tua app in buona salute ed evita di introdurre tonnellate di bug.
L'automatizzazione dei test ti fa effettivamente testare più frequentemente. Immagina se devi testare qualcosa per la quarantesima volta per qualche motivo. Se è solo un po 'di tempo, quanto sarà facile annoiarsi e saltare del tutto il processo? Questo genere di cose è il primo passo su una china scivolosa dove puoi salutare una percentuale decente di copertura del codice addio.
I test funzionano come documentazione. Eh? Le specifiche che scrivi danno ad altre persone del tuo team un punto di accesso rapido per imparare un nuovo codice base e capire cosa dovrebbe fare. Scrivere il tuo codice in RSpec, per esempio, è molto espressivo e forma blocchi di codice altamente leggibili che raccontano una storia se fatti bene. Poiché può essere scritto in modo molto descrittivo pur essendo un Domain Specific Language (DSL) molto conciso, RSpec colpisce due piccioni con una fava: non essendo prolisso nelle sue API e fornendoti tutti i mezzi per scrivere scenari di test altamente comprensibili. Questo è quello che mi è sempre piaciuto e perché non sono mai stato molto gentile con Cucumber, che stava risolvendo lo stesso problema in un modo eccessivamente amichevole con il cliente, penso.
Possono ridurre al minimo la quantità di codice che scrivi. Invece di impazzire come un matto, provando cose più freestyle, la pratica del test-driving del tuo codice ti consente di scrivere solo il codice necessario per superare i test. Nessun codice in eccesso. Una cosa che sentirai spesso nella tua carriera futura è che il miglior codice è un codice che non devi scrivere o qualcosa del genere. Perché? Molto spesso, le soluzioni più eleganti implicano meno quantità di codice e inoltre, codice che non si scrive, che potrebbe non essere necessario, non causerà alcun errore futuro e non dovrà essere mantenuto. Quindi, prima di scrivere i test, prima di scrivere l'implementazione, ti viene dato un chiaro focus su quale problema devi risolvere in seguito. Scrivere solo il codice necessario e non casualmente di più è forse un effetto collaterale sottostimato che TDD può fornirti.
Hanno un effetto positivo sul tuo design. Per me, capire questa parte ha acceso una lampadina e mi ha fatto apprezzare davvero tutta la questione del test. Quando si scrivono le implementazioni su scenari di test molto focalizzati, molto probabilmente il tuo codice sarà molto più compartimentato e modulare. Dato che siamo tutti amici di DRY- "Non ripeterti!" - e il più piccolo accoppiamento tra componenti nella tua app possibile, questa è una disciplina semplice ma efficace per realizzare sistemi che sono stati progettati bene dall'inizio alla fine. Questo aspetto è il vantaggio più importante, penso. Sì, anche gli altri sono fantastici, ma quando i test portano anche a app la cui qualità è migliore a causa di un design raffinato, direi Jackpot!
Si riduce anche ai soldi. Quando hai un'app stabile, facile da mantenere e facile da cambiare, a lungo termine risparmierai un bel po 'di soldi. La complessità non necessaria può infestare facilmente i progetti e la motivazione non sarà al massimo storico quando la tua squadra deve combattere il tuo codice perché è fragile e mal progettato. Una buona progettazione dell'applicazione può assolutamente supportare i tuoi obiettivi aziendali e viceversa. Vuoi introdurre alcune nuove funzionalità che sono fondamentali per la tua azienda, ma stai costantemente combattendo la tua architettura perché è stata costruita sulla sabbia? Certo che no, e tutti abbiamo visto molti esempi di aziende che sono rapidamente scomparse per quella ragione esatta. Le buone abitudini di prova possono essere una linea di difesa efficace per tali situazioni.
Un altro obiettivo importante è la qualità del codice stesso. Il software che scrivi dovrebbe essere di facile comprensione per gli altri sviluppatori, per quanto possibile, almeno. I test possono davvero aiutare a trasmettere la funzionalità e l'intento della tua applicazione, e non solo agli altri membri di un team, ma anche al tuo sé futuro. Se non tocchi una certa parte del tuo codice per un po 'di tempo, sarà davvero utile rinfrescare la memoria di come e perché hai scritto un pezzo di software con la documentazione che uno strumento come RSpec fornisce - e RSpec fa questo davvero bene, eccezionalmente in realtà.
Poiché il tuo codice cambierà sempre, il refactoring del tuo codice sarà e dovrebbe sempre essere parte dello sviluppo del tuo software. E poiché il cambiamento è così radicato in questo processo, è necessario assicurarsi che questi cambiamenti non generino effetti collaterali inaspettati in luoghi sorprendenti. La suite di test offre una rete di sicurezza piuttosto fitta per sentirsi più a suo agio e liberi di refactoring con gusto. Questo aspetto, accanto ai vantaggi del design che TDD può offrirti, è il mio vantaggio preferito con cui una suite di test può aiutarti. La modifica e l'estensione del codice è una componente essenziale per innovare sul tuo "prodotto" già rilasciato e ti serve uno strumento che ti dia la massima libertà possibile con quel processo. Non sono sicuro che le persone che sono critiche nello scrivere una vasta suite di test siano molto preoccupate per questo aspetto.
Avrai buone possibilità di creare nuove cose più velocemente nelle fasi successive perché il feedback della suite di test ti darà un feedback sui tuoi errori, bug e limitazioni, molto più velocemente di quanto un umano possa testare, ovviamente. Inoltre, ti darà la sicurezza di lavorare con una rete di sicurezza che diventa ancora più preziosa più a lungo vai.
Nelle tue app, specialmente se sono cresciute in modo significativo, vuoi essere in grado di fidarti del tuo software. La copertura del 100% del codice sembra molto più dolce quando si dispone di un sito che ha un paio di anni e viene toccato da centinaia di sviluppatori. Essere in grado di fidarsi del nuovo codice che introduci e di crearne uno è una delle benedizioni dello sviluppo del software che i soldi non possono comprare più tardi.
rota nuovo tuo_app -T
-T consente di saltare Test Unit, il framework di test fornito con Rails.
group: development,: test do gem 'rspec-rails' end
fascio
Dopodiché è necessario eseguire un generatore fornito con RSpec:
rails genera rspec: installa
crea .rspec crea spec create spec / spec_helper.rb crea spec / rails_helper.rb
Ciò che fa è impostare la struttura di base per i tuoi test RSpec all'interno di Rails. Come puoi vedere dall'output precedente, questo generatore ha inizializzato a spec directory con alcuni file di cui avrai bisogno in seguito. Il .RSpec file è un file di configurazione che non avremo bisogno di manipolare per ora. Volevo solo farti sapere cosa hai di fronte a te. Gli altri file sono auto-esplicativi, ma volevo menzionare le loro differenze.
Accentsconagua
spec_helper.rb è per le specifiche che non dipendono da Rails.rails_helper.rb, d'altra parte, è per le specifiche che dipendono da questo.Ciò che non è ovvio è che uno di questi file deve essere richiesto in cima ai file delle specifiche (file di test) per poter eseguire i test. Diamo una rapida occhiata! Quando generi un modello tramite:
rails genera il modello dummy_model name: string
invoca active_record crea db / migrate / 20160521004127_create_dummy_models.rb crea app / models / dummy_model.rb richiama rspec crea spec / models / dummy_model_spec.rb
Non solo le rotaie hanno creato l'associato _spec.rb file per te, anche le tue specifiche avranno automaticamente richiede 'rails_helper' per impostazione predefinita sopra i tuoi file spec. Ciò significa che sei pronto ad andare, subito.
richiede 'rails_helper' ...
Quindi, con questa configurazione, puoi testare l'app Rails, i tuoi modelli, ad esempio, e RSpec non si confonderà con le classi di modelli usate in Rails. Questo è necessario da richiedere ogni volta che hai bisogno di cose del genere ActiveRecord, ApplicationController e così via. Quindi questo è il tuo normale scenario e quindi dovrebbe essere la tua prima scelta logica come principiante.
richiedendo spec_helper.rb, d'altra parte, genera un errore se si scrivono test che includono la logica aziendale dall'app Rails. In questo scenario, RSpec non saprebbe di cosa stai parlando quando vuoi testare un modello di Rails, per esempio.
Così lunga storia super breve, spec_helper non carica Rails-questo è tutto! Certo, puoi scatenarti con le configurazioni, ma questo non è nulla di cui ti voglio preoccupare adesso. Concentriamoci sulle basi, su come eseguire i test e la sintassi. Questo dovrebbe essere sufficiente per i principianti. Andiamo avanti!
Sei pronto per eseguire i test. RSpec richiede che i tuoi file di test abbiano un suffisso specifico come _spec per capire quali file eseguire. Se si utilizza un generatore, questo non è un problema, ma se si desidera scrivere i file di test da soli, questo è il modo in cui devono terminare. Quindi dovrai mettere un file come your_first_test_spec.rb nel tuo spec elenco.
Usare il generatore per creare un modello fittizio già fornito con noi spec / modelli / dummy_model_spec.rb. Non male! Una cosa che resta da fare prima che i test siano pronti:
rake db: migrate rake db: test: prepara
Questi comandi eseguono la migrazione per il modello fittizio che abbiamo generato in precedenza e impostano anche il database di test con quel modello. Ora eseguiamo effettivamente il test:
rastrello
Il rastrello il comando eseguirà tutti i test, la suite di test completa. Di solito dovresti usare questo comando quando hai finito alcune funzionalità e vuoi esercitare l'intera suite di test.
* In sospeso: (I guasti elencati qui sono previsti e non influenzano lo stato della tua suite) 1) DummyModel aggiunge alcuni esempi (o cancella) / Users / vis_kid / projects / rspec-test-app / rspec-dummy / spec / models / dummy_model_spec .rb # Non ancora implementato # ./spec/models/dummy_model_spec.rb:4 Terminato in 0,00083 secondi (i file impiegavano 1,94 secondi per caricarsi) 1 esempio, 0 fallimenti, 1 in attesa
Congratulazioni! Hai appena eseguito il tuo primo test RSpec. Non così male, vero? Naturalmente, questo era un test fittizio per ora, con il codice di prova fittizio generato da Rails. La versione più mirata dell'esecuzione dei test, in realtà molte più opzioni rispetto a quella, è l'esecuzione di un singolo file, ad esempio. Come questo:
bundle exec rspec spec / models / dummy_model_spec.rb
Questo eseguirà solo un singolo file di test invece dell'intera suite di test. Con le applicazioni più grandi che dipendono da una grande quantità di file di test, questo diventerà un risparmio in tempo reale. Ma in termini di risparmio di tempo e specificità del test, questo è solo un graffio sulla superficie, per essere sinceri. Penso che copriremo di più su come radere una quantità significativa di tempo durante i test nel terzo articolo di questa serie. Vediamo fino a dove arriviamo!
L'altro modo di esercitare l'intera suite di test è semplicemente eseguendo RSpec-con o senza pacchetto exec, a seconda della configurazione.
bundle exec rspec
Un'altra cosa che dovrei menzionare prima di andare avanti, è anche possibile eseguire solo un sottoinsieme specifico di test. Supponi di voler eseguire tutti i test per il tuo codice modello:
bundle exec rspec spec / models
Facile come quello!
Vi consiglio di iniziare con le nozioni di base e di esaminare alcune altre opzioni fornite da RSpec nei prossimi due articoli. Diamo un'occhiata alla struttura di base di un test e ci immergiamo in acque più avanzate quando ce n'è una fuori mano.
descrivereQuesto sarà il tuo pane e burro perché organizza le tue specifiche. Puoi fare riferimento a stringhe o classi stesse:
descrivi User do end descrivere 'Some string' do end
descrivere le sezioni sono gli elementi costitutivi fondamentali per organizzare i test in gruppi logici e coerenti da testare. Fondamentalmente, un ambito per le diverse parti della tua applicazione che vuoi testare.
descrivi Utente fai ... fine descrivi Ospite do ... fine descrivi Attaccante do ... fine
Un buon consiglio è di stringere ancora di più la tua portata. Poiché alcune classi cresceranno in modo significativo, non è una buona idea avere tutti i metodi che vuoi testare per una classe in un singolo descrivere bloccare. È possibile creare più di questi blocchi, ovviamente, e concentrarli invece su metodi di istanza o classe. Per rendere più chiaro il tuo intento, tutto ciò che ti serve è fornire il nome della classe con una stringa aggiuntiva che faccia riferimento al metodo che vuoi testare.
descrivi l'agente, '#favorite_gadget' ... termina l'agente, '#favorite_gun' do ... fine descrive l'agente, '.gambler' do ... end
In questo modo ottieni il meglio da entrambi i mondi. Incapsulate test correlati nei loro gruppi rappresentativi mantenendo le cose focalizzate e di dimensioni adeguate. Per gli utenti molto nuovi a Ruby land, dovrei dirlo # fa semplicemente riferimento a un metodo di istanza mentre il punto . è riservato ai metodi di classe. Poiché sono dentro stringhe, non hanno implicazioni tecniche qui, ma segnalano il tuo intento ad altri sviluppatori e al tuo sé futuro. Non dimenticare la virgola dopo il nome della classe: non funzionerà senza di essa! Tra un minuto, quando arriveremo aspettarsi, Ti mostrerò perché questo approccio è super conveniente.
essoNell'ambito di descrivere gruppi, usiamo un altro scopo di esso blocchi. Questi sono fatti per gli esempi reali sotto test. Se vuoi testare il metodo di istanza #favorite_gadget sul Agente classe, sarebbe simile a questo:
descrivi l'agente, '#favorite_gadget' fallo 'restituisce un oggetto, il gadget preferito dell'agente' do ... end end
La stringa che fornisci al esso il blocco funziona come la documentazione principale per il test. Al suo interno, si specifica esattamente quale tipo di comportamento si desidera o si aspetta dal metodo in questione. La mia raccomandazione è di non esagerare e di essere troppo prolisso ma allo stesso tempo di non essere eccessivamente criptico e confondere gli altri con descrizioni eccessivamente intelligenti.
Pensa a cosa può e dovrebbe portare la realizzazione più piccola e più semplice di questa parte del puzzle. Quanto meglio scrivi questa parte, tanto migliore sarà la documentazione complessiva per la tua app. Non affrettare questa parte perché è solo una stringa che non può causare danni, almeno non in superficie.
aspettarsi()Ora stiamo diventando più al centro delle cose. Questo metodo ti consente di verificare o falsificare la parte del sistema che vuoi testare. Torniamo al nostro esempio precedente e vediamo in azione (limitata):
descrivi Agent, '#favorite_gadget' fallo 'restituisce un elemento, il gadget preferito dell'agente' si aspetta (agent.favorite_gadget) .to eq 'Walther PPK' end end
aspettarsi() è la "nuova" sintassi dell'asserzione di RSpec. In precedenza abbiamo usato dovrebbero anziché. Storia diversa, ma volevo menzionarlo nel caso ci si imbattesse in esso. aspettarsi() si aspetta che tu fornisca un oggetto ed eserciti qualsiasi metodo sotto test su di esso. Alla fine, scrivi il risultato asserito sul lato destro.
Hai la possibilità di percorrere il percorso positivo o negativo con .per eq o .non_a eq per esempio (eq essere breve per pari ovviamente). Puoi sempre attivare la logica, indipendentemente dalle tue esigenze. Eseguiamo questo test privo di assenso e concentriamoci sull'output ottenuto grazie alla nostra configurazione di test:
rspec spec / models / agent_spec.rb
Errori: 1) Agent # favorite_gadget restituisce un elemento, il gadget preferito dell'agente Errore / Errore: expect (agent.favorite_gadget) .to eq 'Walther PPK'
Legge piuttosto bene, non è vero?? ** "Agent # favorite_gadget restituisce un oggetto e il gadget preferito di agente"** ti dice tutto ciò che devi sapere:
Se avessimo lasciato la stringa che descrive il metodo nel descrivere blocco, quindi l'output sarebbe stato molto meno chiaro e leggibile:
Descrivi Agent fa 'restituisce un elemento, il gadget preferito dell'agente' si aspetta (agent.favorite_gadget) .to eq 'Walther PPK' end end
Errori: 1) Agente restituisce un elemento, il gadget preferito dell'agente Errore / Errore: expect (agent.favorite_gadget) .to eq 'Walther PPK'
Certo, ci sono altri modi per aggirare e gestire questo problema, passando queste informazioni tramite il tuo esso blocco, per esempio, ma l'altro approccio è semplice e funziona. Qualunque cosa faccia fluire il tuo sangue, naturalmente!
Le migliori pratiche nei test raccomandano di comporre i nostri test in quattro fasi distinte:
Queste quattro fasi sono principalmente per la leggibilità e per fornire ai test una struttura convenzionale. È un cosiddetto modello di test, in pratica, una pratica che la comunità ha ampiamente accettato di essere utile e raccomandata. L'intero tema dei pattern è una profonda tana di coniglio, quindi sappi che lascerò un mazzo per non confondere i principianti tra di voi fino alla morte.
Durante l'installazione, si prepara lo scenario in cui deve essere eseguito il test. Nella maggior parte dei casi, questo includerà i dati necessari per essere pronti per un qualche tipo di esercizio. Piccolo consiglio: non complicare eccessivamente le cose e impostare solo la quantità minima necessaria per far funzionare il test.
agente = Agent.create (nome: 'James Bond') mission = Mission.create (nome: 'Moonraker', stato: 'Briefed')
Questa parte esegue effettivamente la cosa che vuoi testare in questa specifica. Potrebbe essere semplice come:
status = mission.agent_status
Ora verifichi se la tua affermazione sul test è stata soddisfatta o meno. Quindi testerai il sistema in base alle tue aspettative.
aspettati (stato) .non a eq 'MIA')
Il framework si occupa dei problemi di pulizia della memoria e del database, in pratica un reset. Non c'è niente da gestire a questo punto. L'obiettivo è quello di ottenere uno stato incontaminato per eseguire nuovi test senza sorprese da quelli attualmente in esecuzione. Vediamo cosa significherebbe in un esempio fittizio:
descrivi l'Agent, '#favorite_gadget' fallo 'restituisce un elemento, il gadget preferito dell'agente' fa # Setup agent = Agent.create (nome: 'James Bond') q = Quartermaster.create (nome: 'Q') q .technical_briefing (agent) # Exercise favorite_gadget = agent.favorite_gadget # Verificare aspettarsi (favorite_gadget). su eq 'Walther PPK' # Teardown è per ora principalmente gestito da RSpec stesso end end
Come puoi vedere, in questo esempio abbiamo separato l'esercizio e verificato le fasi chiaramente l'una dall'altra, mentre negli altri esempi fittizi sopra, aspettarsi (agente.favorite_gadget) .per eq 'Walther PKK, abbiamo mescolato entrambe le fasi insieme. Entrambi sono scenari validi e hanno il loro posto. Inoltre, le nuove linee aiutano a separare visivamente il modo in cui il test è strutturato.
Ora arriva la parte difficile, cosa testare e come. A mio avviso, questo è l'aspetto del test che è più confuso per i nuovi arrivati - e in modo comprensibile! Sei nuovo nel linguaggio e nella struttura e spesso non sai nemmeno quello che non sai. Come si scrivono i test per questo? Ottima domanda.
Sarò molto franco, non lo farete, molto probabilmente, e non lo farete per un bel po '. Trovarsi a proprio agio con questa roba richiede un po 'di tempo. Quando hai un mentore o frequenti un campo di addestramento e simili, hai l'opportunità di imparare direttamente da persone esperte. In tal caso, i tuoi progressi in questo reparto saranno diversi, ovviamente.
D'altra parte, se sei come tanti altri là fuori - ti stai insegnando questa roba, la pazienza sarà la chiave. La lettura di tutti i libri e gli articoli ti porta sicuramente nella giusta direzione, ma penso che i test richiedano un sacco di pezzi di puzzle più avanzati in modo che tu possa avere un senso completo e, forse ancora più importante, prima di sentirti a tuo agio con esso.
La "buona" novità è che non è insolito e siamo stati tutti lì. La perseveranza è importante. Puoi farlo, non è una scienza missilistica, ma ci vorrà un po 'prima che tu possa scrivere un'applicazione in modo efficace dal contrario, dal punto di vista dei test, intendo. Per ora, continua a spingere, divertiti, fai errori, scrivi app, copi tutorial e quant'altro, finché la lampadina non si spegne.
Quando scrivi i tuoi test individuali, vuoi fare in modo che i loro oggetti facciano la cosa più semplice possibile per raggiungere il tuo obiettivo: i test altamente focalizzati sono davvero fondamentali. Desiderate progettare la vostra applicazione con passaggi molto semplici e poi seguire gli errori che la vostra suite di test sta fornendo.
Implementa solo ciò che è necessario per ottenere l'app verde. Non più, non meno! Questa è la parte "guidata" nello sviluppo basato sui test. Il tuo lavoro è guidato dalle esigenze dei tuoi test.
