Unlimited WordPress themes, graphics, videos & courses! Unlimited asset downloads! From $16.50/m
Advertisement
  1. Code
  2. Rspec
Code

RSpec test per principianti, parte 3

by
Length:LongLanguages:
This post is part of a series called RSpec Testing for Beginners.
RSpec Testing for Beginners, Part 2

Italian (Italiano) translation by Mirko Pizii (you can also view the original English article)

In questo articolo finale su RSpec basics, copriamo alcune parti incerto si può e si dovrebbe evitare, come si dovrebbero comporre i test, perché si dovrebbe evitare il database per quanto possibile e come aumentare la velocità fino la suite di test.

Argomenti

  • Velocità di prova
  • Database dei colli di bottiglia
  • Preloader di primavera
  • RSpec incerto convenienze
  • Ospiti di mistero
  • Codice inline
  • Metodi di estrazione

Ora che avete le basi sotto la cintura, dovremmo prendere il tempo per discutere alcune parti incerto di RSpec e TDD — alcuni problemi che possono facilmente essere abusati e alcuni aspetti negativi di utilizzare parti di RSpec di DSL unreflected. Voglio evitare ripieno un sacco di concetti avanzati nei vostri cervelli TDD appena schiusi, ma mi sento alcuni punti devono essere effettuate prima di andare sul vostro primo test Sprea. Inoltre, creazione di un gruppo di test lento a causa di cattive abitudini che sono facilmente evitabili è qualcosa che si può migliorare come un principiante subito.

Certo, ci sono alcune cose che è necessario per ottenere più esperienza con prima vi sentirete confortevole ed efficace con i test, ma scommetto che vi sentirete meglio fin dall'inizio anche se si toglie alcune delle migliori pratiche che miglioreranno le caratteristiche del tuo collettore con fuori le vostre abilità di stretching troppo molto in questo momento. È anche una piccola finestra in concetti più avanzati che sarà necessario raccogliere nel corso del tempo alla sperimentazione "master". Mi sento che non dovrei disturbarti troppo all'inizio con questi perché potrebbe solo sentire contorto e confuso prima di aver sviluppato il quadro più ampio che lega tutto insieme ordinatamente.

Velocità di prova

Cominciamo con velocità. Una suite veloce è nulla di quanto accade per caso; si tratta di manutenzione "costante". Ascoltando i test molto frequentemente è piuttosto importante — almeno se siete a bordo con TDD e hanno bevuto il Kool-Aid per un po' di tempo — e veloce test suite lo rendono molto più ragionevole di prestare attenzione a dove le prove sono guidarvi.

Velocità di prova è qualcosa di che si dovrebbe prendere cura. È essenziale per rendere un'abitudine regolare il test e tenerlo divertente. Vuoi essere in grado di eseguire rapidamente i test affinché si ottiene un rapido feedback mentre si sviluppa. Il tempo che impiega per esercitare la suite di test, tanto più probabile sarà che saltare test sempre più fino a quando non fai solo alla fine prima che volete spedire una nuova funzionalità.

Questo potrebbe non sembrare che male all'inizio, ma questo non è un problema banale. Uno dei vantaggi principali di un gruppo di test è che guida la progettazione dell'applicazione — per me questo è probabilmente la più grande vittoria da TDD. Più esecuzioni di test rendono questa parte praticamente impossibile perché è molto probabile che non eseguirli in modo da non rompere il vostro flusso. Rapido test garantiscono che non hai motivo di non eseguire i test.

Si può vedere questo processo come un dialogo tra l'utente e il gruppo di test. Se questa conversazione diventa troppo lento, è davvero doloroso continuare. Quando l'editor di codice offre la possibilità di eseguire anche i test, si dovrebbe sicuramente fare uso di questa funzione. Questo drammaticamente aumentare la velocità e migliorare il vostro flusso di lavoro. Ogni tempo tra il vostro editor e una shell per eseguire i test di commutazione invecchia molto rapidamente. Ma dal momento che questi articoli sono destinati a newbie programmatori, non mi aspetto di impostare subito il tuo strumenti come questo. Ci sono altri modi che è possibile migliorare questo processo senza bisogno di armeggiare con il vostro editor subito. È bene sapere, però, e vi consiglio di fare tale parte di strumenti del flusso di lavoro.

Inoltre, essere consapevoli del fatto che hai già imparato a tagliare i test e che non è necessario eseguire il test completo tutto il tempo. È possibile facilmente eseguire file singoli o singola it blocchi — tutto all'interno di un editor di codice in grado senza mai lasciarlo per il terminale. È possibile concentrarsi il test sulla linea sotto test, per esempio. Che si sente come per magia, ad essere sinceri, non diventa mai noioso.

Database dei colli di bottiglia

Scrittura al database di troppo — molto spesso inutilmente così — è un modo sicuro per rapidamente di rallentare significativamente la suite di test. In molti scenari di test, può falsificare i dati che è necessario impostare un test e concentrarsi solo sui dati che sono direttamente sotto test. Non hai bisogno di accedere al database per tutti è il più delle volte — soprattutto non per le parti che non sono direttamente sotto test e supportano solo il test in qualche modo: un utente loggato mentre si sta testando l'importo da pagare a un check-out, ad esempio. L'utente è come un extra che può essere falsificato fuori.

Si dovrebbe cercare di farla franca non colpire il database quanto possibile perché questo morde una grossa fetta fuori un gruppo di test lento. Inoltre, cercare di non installare troppi dati se non devi affatto. Che può essere molto facile dimenticare soprattutto con test di integrazione. Gli unit test sono spesso molto più concentrato per definizione. Questa strategia si rivelerà molto efficace nell'evitare di rallentare i gruppi di test nel corso del tempo. Scegli le dipendenze con grande cura e vedere che cosa è la più piccola quantità di dati che ottiene i test da passare.

Non voglio andare in una qualsiasi ulteriori specifiche per ora — è probabilmente un po' troppo presto nella vostra traiettoria per parlare di stub, spie, falsi e roba. Ti confonde qui con tali concetti avanzati sembra controproducente, e vi imbatterete in questi abbastanza presto. Ci sono molte strategie per test rapido che coinvolgono anche altri strumenti di RSpec. Per ora, cercare di avvolgere la testa intorno l'immagine più grande con RSpec e testing in generale.

Volete anche lo scopo di tutto ciò che prova una sola volta — se possibile. Non testare nuovamente la stessa cosa più e più volte — che è solo uno spreco. Ciò si verifica principalmente da incidente e/o decisioni di cattiva progettazione. Se iniziato ad avere prove che sono lenti, questo è un posto facile per effettuare il refactoring per ottenere una spinta di velocità.

La maggior parte dei test dovrebbe essere anche il livello di unità, prova i tuoi modelli. Questo non solo manterrà le cose veloce ma vi fornirà anche con il più grande bang per il dollaro. Test di integrazione che mettono alla prova i flussi di lavoro interi — imitando il comportamento dell'utente in grado di riunire un gruppo di componenti e il loro test in modo sincrono — dovrebbe essere la più piccola parte della vostra piramide test. Queste sono piuttosto lenti e "costosi". Forse 10% del tuo test complessivo non è irrealistico per sparare — ma questo dipende, immagino.

Esercitare il database quanto possibile può essere difficile perché devi imparare parecchi più strumenti e tecniche per raggiungere questo obiettivo in modo efficace, ma esso è essenziale per crescere gruppi di test che sono ragionevolmente veloce — abbastanza veloce per davvero eseguire frequentemente i test.

Preloader di Spring

Il server di primavera è una caratteristica delle rotaie e precarica dell'applicazione. Questa è un'altra strategia semplice per aumentare significativamente la velocità di prova — destra fuori dalla scatola, dovrei aggiungere. Ciò che fa è semplicemente mantenere l'applicazione in esecuzione in background senza bisogno di boot con ogni singolo test run. Lo stesso vale per le attività di Rake e migrazioni; questi verrà eseguito più velocemente, anche.

Dal 4.1 Rails, primavera è stata inclusa in Rails — automaticamente aggiunto il Gemfile — e non devi fare molto per avviare o arrestare questo preloader. In passato abbiamo avuto di cablare i nostri strumenti di scelta per questo — che si può ancora fare naturalmente se avete altre preferenze. Ciò che è veramente gentile e premuroso è che verrà riavviato automaticamente se si modificano alcune gemme, inizializzatori o config file — un bello e comodo toccare perché è facile dimenticare di prendersi cura di esso voi stessi.

Per impostazione predefinita è configurato per eseguire rails e rake solo i comandi. Così abbiamo bisogno di impostare fino a eseguire anche con il comando di rspec per eseguire i nostri test. Si può chiedere lo status di primavera in questo modo:

Terminale

Uscita

Poiché l'output ci ha detto che la primavera non è in esecuzione, è semplicemente avviarlo con spring server. Quando si esegue ora lo spring status, si dovrebbe vedere qualcosa di simile a questo:

Uscita

Ora dovremmo controllare quello che la primavera è impostato per precaricare.

Terminale

Uscita

Questo ci dice che molla precarico rotaie per rake e comandi di rails e nient'altro finora. Che abbiamo bisogno di prendersi cura di. Abbiamo bisogno di aggiungere il gioiello spring-commands-rspec, e i nostri test sono quindi pronti per essere precaricata.

Gemfile

Terminale

Io ricambio l'output da bundle install; Sono sicuro che avete già visto oltre la tua parte di esso. In esecuzione bundle exec spring binstub rspec, d'altra parte, genera un file di bin/rspec che aggiunge fondamentalmente essere precaricata di Spring. Vediamo se questo ha funzionato:

Terminale

Questo ha creato qualcosa chiamato un binstub — un wrapper per i file eseguibili come rails, rake, bundle, rspec e tali — così che quando si utilizza il comando di rspec userà Spring. Per inciso, tale binstubs garantire che si eseguono questi eseguibili nell'ambiente giusto. Consentono inoltre di eseguire questi comandi da ogni directory nella tua app — non solo dalla radice. Un altro vantaggio di binstubs è che non devi anteporre bundle exec con tutto.

Uscita

Sembra a-OK! Facciamo arrestare e riavviare il server di primavera prima di procedere:

Terminale

Così ora si esegue il server di primavera in una finestra di terminale dedicata, e si eseguono i test con una sintassi leggermente diversa in un altro. Abbiamo semplicemente bisogno di prefisso ogni test eseguito con il comando di spring:

Terminale

Questo viene eseguito tutti i tuoi file spec, naturalmente. Ma non c'è nessun bisogno di fermarsi lì. È inoltre possibile eseguire file singoli o con tag test via primavera — nessun problema! E tutti saranno essere un fulmine veloce ora; su piccoli gruppi di test sembrano davvero quasi istantanee. Come se non bastasse, è possibile utilizzare la stessa sintassi per i rails e rake i comandi. Bello, eh?

Terminale

Così, otteniamo primavera fuori dalla scatola per velocizzare le cose in Rails, ma non dobbiamo dimenticare di aggiungere questo piccolo gioiello per sapere come giocare a palla con RSpec primavera.

RSpec incerto convenienze

Le cose menzionate in questa sezione sono probabilmente buone evitare, finché è possibile trovare un'altra soluzione per loro. Uso eccessivo di alcuni delle convenienze RSpec può portare allo sviluppo di cattive abitudini test — a quelli molto meno incerto. Quello che discuteremo qui è conveniente sulla superficie ma potrebbe mordere un po' più avanti lungo la strada.

Non dovrebbero essere considerate AntiPatterns — cose da evitare subito — ma piuttosto visto come "odori", cose che si dovrebbe essere attenti e che potrebbe introdurre un significativo costo è spesso non vogliono pagare. Il ragionamento per questo coinvolge poche ulteriori idee e concetti che voi come un principiante sono molto probabilmente non hanno familiarità con ancora — e francamente potrebbe essere un po ' sopra la vostra testa ancora a questo punto — ma almeno dovrei mandare tu casa con alcune bandiere rosse a pensare e a impegnarsi alla memoria per il momento.

  • let

Avendo un sacco di riferimenti let può sembrare molto conveniente in un primo momento — soprattutto perché si asciugano le cose su un po'. Sembra che un'estrazione ragionevolmente buona in un primo momento di averli nella parte superiore dei vostri file, ad esempio. D'altra parte, possono facilmente dare si fatica a capire il tuo codice se si visita test specifici alcuni notevole quantità di tempo in seguito. Non avendo il set di dati all'interno di blocchi let non aiuta la comprensione dei test troppo. Vale a dire non è così banale come può sembrare in un primo momento, soprattutto se altri sviluppatori sono coinvolti che hanno bisogno di leggere il tuo lavoro pure.

Questo tipo di confusione diventa molto più costoso, che più sviluppatori sono coinvolti. Non è solo richiede molto tempo se dovete dare la caccia a let riferimenti più e più volte, è anche stupido perché sarebbe stato evitabile con il minimo sforzo. Chiarezza è re, ci sono dubbi. Un altro argomento per mantenere questo dati in linea è che la suite di test sarà meno fragile. Non volete costruire un castello di carte che diventa più instabile con ogni delusione che si nasconde let lontani da ogni test. Probabilmente imparato che l'utilizzo di variabili globali non è una buona idea. In questo senso, let che è semi-globale all'interno del vostro file spec.

Un altro problema è che sarà necessario testare un sacco di diverse varianti, diversi stati per scenari simili. Si esaurirà presto let ragionevolmente denominate istruzioni per coprire tutte le diverse versioni, potrebbe essere necessario — o finire con un pagliaio di tonnellate di variazioni di stato denominato allo stesso modo. Quando si impostano i dati in ogni test direttamente, non hai quel problema. Le variabili locali sono economici, altamente leggibile e non si scherza con altri ambiti. Infatti, possono essere ancora più espressive perché non è necessario considerare le tonnellate di altri test che potrebbe avere un problema con un determinato nome. Si desidera evitare la creazione di un altro modello DSL in cima il quadro che tutti hanno bisogno di decifrare per ogni test che utilizza let. Spero che si sente molto come uno spreco di tempo per tutti.

  • before & after

Salvare le cose come before, after e le sue variazioni per le occasioni speciali e non lo uso tutto il tempo, tutto il posto. Vederlo come uno dei grossi calibri che si tira fuori per le cose di meta. Ripulire i dati è un buon esempio che è anche meta per ogni singolo test da affrontare. Si desidera estrarre che, naturalmente.

Ospiti di mistero

Spesso potete mettere le cose let nella parte superiore di un file e nascondere lontano questi dettagli da altri test che utilizzano loro andando giù il file. Vuoi avere le informazioni pertinenti e i dati più vicino possibile alla parte dove si esercita in realtà il test — non miglia di distanza rendendo individuali prove più oscuro.

Alla fine, ci si sente come troppa corda per impiccarsi con, perché let che introduce ampiamente condiviso infissi. Che fondamentalmente si rompe per dati di test fittizio cui ambito non è abbastanza stretto.

Questo porta facilmente ad un odore principali chiamati "mystery guest". Ciò significa che si dispone di dati di test che compare dal nulla o sono semplicemente essere supposto. Spesso sarà necessario loro la caccia prima per comprendere una prova — soprattutto se è passato del tempo da quando hai scritto il codice o se siete nuovi a un attributo codebase. È molto più efficace definire il tuo test di dati in linea esattamente dove è necessario — nel setup di un particolare test e non in una portata molto più ampia.

Agente Spec

Quando si guarda a questo, si legge molto bene, giusto? È succinto, un one-liner, abbastanza pulito, no? Let's non ingannare noi stessi. Questo test non ci dice molto circa l'agente in questione, e non ci dice tutta la storia. I dettagli di implementazione sono importanti, ma non stiamo vedendo niente di tutto questo. L'agente sembra sono stati creati da qualche altra parte, e che avremmo dovuto dare la caccia a prima al fine di comprendere appieno che cosa sta succedendo qui. Allora, forse sembra elegante sulla superficie, ma si tratta con un prezzo pesante.

Sì, i test non potrebbero finire per essere a quadrante asciutto tutto il tempo a riguardo, ma questo è un piccolo prezzo da pagare per essere più espressivi e più facile da capire, credo. Certo ci sono eccezioni, ma dovrebbero davvero essere semplicemente applicati a situazioni eccezionali che dopo che hai esaurito le opzioni che pure Ruby offre subito.

Con un ospite misterioso, devi scoprire da dove provengono i dati, perché è importante e ciò che sono davvero la sua specificità. Non vedendo i dettagli di implementazione in un particolare test solo rende la vita più difficile che ha bisogno di essere. Voglio dire, fare ciò che si sente come se si lavora su propri progetti, ma quando gli altri sviluppatori sono coinvolti, sarebbe bello pensare a rendere la loro esperienza con il codice più liscia possibile.

Come con molte cose, naturalmente, le cose essenziali si trova nei dettagli, e non volete mantenere se stessi e gli altri all'oscuro di quelle. Leggibilità, concisione e la convenienza di let non dovrebbe venire a costo di perdere la chiarezza sulla misdirection e dettagli di implementazione. Si desidera che ogni singolo test per raccontare la storia completa e fornire tutto il contesto per capirlo subito.

Codice inline

Lunga storia breve, si desidera avere prove che sono facili da leggere e più facile ragionare — una prova-di-prova-base. Provare a specificare tutto il necessario nel test effettivo — e non di più. Questo tipo di rifiuti comincia a "puzzare" proprio come qualsiasi altro tipo di spazzatura. Ciò implica anche che si dovrebbero aggiungere i dettagli necessari per test specifici più tardi possibile — quando è creare dati di test globale, all'interno dello scenario reale e non in un posto remoto. Il suggerito utilizza delle offerte let un diverso tipo di comodità che sembra opporsi a questa idea.

Cerchiamo di avere un altro andare con l'esempio precedente e attuarlo senza il problema di mystery guest. La soluzione riportata di seguito, troveremo tutte le informazioni pertinenti per la prova in linea. Possiamo stare giusti in questa spec se non riesce e non ha bisogno di cercare ulteriore info alcuni altro luogo.

Agente Spec

Sarebbe bello se let lasciate che configuri barebones dati di test che si potrebbe migliorare su base di necessità di conoscere in ogni test specifici, ma questo è non come lasciare che sta rotolando. Ecco come usare fabbriche tramite Factory Girl in questi giorni.

Vi risparmio i dettagli, soprattutto perché ho scritto un paio di pezzi su di esso già. Qui sono i miei articoli su misura newbie 101 e 201 su cosa Factory Girl ha da offrire, se siete già curiosi di sapere che. È scritto per gli sviluppatori senza tonnellate di esperienza pure.

Diamo un'occhiata a un altro semplice esempio che fa un buon uso di supportare dati di test che sono impostati in linea:

Agente Spec

Come potete vedere, abbiamo tutte le informazioni che questo test ha bisogno in un unico luogo e non hanno bisogno di dare la caccia a eventuali specifiche alcuni altro luogo. Si racconta una storia e non è oscura. Come già detto, questo non è la strategia migliore per codice asciutto. Il payoff è buono, però. Chiarezza e leggibilità supera questo po ' di codice ripetitivo da un colpo lungo — specialmente in grandi basi di codice.

Ad esempio, si scrive alcune funzionalità nuove, apparentemente non correlati e improvvisamente questo test inizia a fallire come danni collaterali e non hai toccato questo file spec nel Medioevo.

Pensi che sarai felice se avete bisogno di decifrare i componenti di installazione in primo luogo al fine di comprendere e risolvere questo test fallito prima di continuare con una funzione completamente diversa che si sta lavorando? Non credo! Si desidera uscire appena possibile questa spec "indipendente" e tornare a finire l'altra caratteristica.

Quando trovate tutti i dati di prova proprio lì dove i test diranno dove fallisce, si aumenta la probabilità da un colpo lungo di fissare questo rapidamente senza dover "scaricare" una parte completamente diversa dell'app nel vostro cervello.

Metodi di estrazione

Si può pulire e asciugare il tuo codice significativamente scrivendo i tuo metodi di supporto. Non c'è alcuna necessità di utilizzare RSpec DSL per qualcosa di economico come un metodo di Ruby.

Diciamo che hai trovato un paio di infissi ripetitivi che stanno cominciando a sentire un po' sporca. Invece di andare con un let o un oggetto, definire un metodo nella parte inferiore di un blocco di descrivere — una convenzione — ed estrarre le comunanze in esso. Se è un po' più ampiamente usato all'interno di un file, è possibile inserire nella parte inferiore del file pure.

Un piacevole effetto collaterale è che non si tratta con tutte le variabili semi-globali in questo modo. Risparmierete anche dal fare un mucchio di cambiamenti in tutto il luogo, se è necessario modificare i dati un po'. Ora si può andare in un posto centrale dove il metodo è definito e interessano tutti i luoghi che è usato in una sola volta. Non male!

Agente Spec

Come potete vedere c'è un po ' di codice di installazione ripetitivo, e vogliamo evitare di scrivere questo più e più volte. Invece, vogliamo solo vedere gli elementi essenziali per questo test e disporre di una build di metodo il resto dell'oggetto per noi.

Agente Spec

Ora il nostro metodo estratto si prende cura delle cose sezione e licence_to_kill e quindi non distrarci dalla prova essenziale con giochi gratificanti. Naturalmente, questo è un esempio fittizio, ma è possibile scalare la sua complessità come avete bisogno. La strategia non cambia. È una tecnica molto semplice refactoring — Ecco perché ho introdurre questo presto — ma uno di quelli più efficaci. Inoltre, lo rende quasi un no-brainer per evitare RSpecs offre gli strumenti di estrazione.

Che cosa si dovrebbe anche prestare attenzione a è espressivo come questi metodi di supporto possono essere senza pagare alcun prezzo supplementare.

Considerazioni finali

Evitando alcune parti di RSpec DSL e fare buon uso di buon ol ' Ruby e principi di programmazione orientata a oggetti è un buon modo per avvicinarsi a scrivere i test. Potete liberamente utilizzare le cose essenziali, descrivere, contesto e it, naturalmente.

Trovare una buona ragione per utilizzare altre parti di RSpec di evitarli finché è possibile. Solo perché le cose possono sembrare conveniente e fantasia non è una ragione sufficiente per utilizzarli — è meglio mantenere le cose più semplici.

Semplice è buono; i test mantiene sana e veloce.

Advertisement
Advertisement
Advertisement
Advertisement
Looking for something to help kick start your next project?
Envato Market has a range of items for sale to help get you started.