Domanda

Quando è consigliabile utilizzare le specifiche per l'applicazione Rails e quando cetriolo (ex RSpec-storie)? So quanto sia il lavoro e attivamente utilizzare specifiche, naturalmente. Ma si sente ancora strano per usare cetriolo. Il mio attuale vista su questo, è che è comodo da usare cetriolo quando si sta implementando l'applicazione per il cliente e non capisco come l'intero sistema dovrebbe funzionare ancora.

Ma cosa succede se sto facendo il mio progetto? Per la maggior parte del tempo, so quanto le parti del sistema interagiscono. Tutto quello che devi fare è scrivere un po 'di unità di test. Quali sono le possibili situazioni in cui avrei bisogno di cetriolo allora?

E, come un corrispondente seconda domanda: devo scrivere spec se scrivo storie di cetriolo? Non sarebbe doppio test della stessa cosa?

È stato utile?

Soluzione

Se non l'hai già, si potrebbe voler controllare eccellente articolo di Dan Nord, Cosa c'è nella una storia? come punto di partenza.

Abbiamo due usi principali per le storie di cetriolo. In primo luogo, perché la forma storia è molto specifico che aiuta a focalizzare l'articolazione del proprietario del prodotto delle caratteristiche che vuole costruito. Questo è il "token per un colloquio" l'uso di storie, e sarebbe utile anche se non abbiamo implementato le storie nel codice. In secondo luogo, quando il processo sta funzionando abbastanza bene che abbiamo storie complete prima abbiamo iniziare a scrivere la funzione (più di un ideale che ci sforziamo di che una realtà quotidiana), avete i vostri criteri di accettazione scritte chiaramente e si sa esattamente cosa e quanto costruire.

Nel nostro Rails lavoro, storie di cetriolo non sostituiscono per i test unitari RSpec. I due vanno mano nella mano. In pratica, i test di unità tendono a guidare lo sviluppo dei modelli e controllori, e le storie tendono a guidare lo sviluppo dei punti di vista (si tende a non scrivere rspec per le nostre opinioni) e forniscono un buon test dell'applicazione nel suo insieme dal punto di vista dell'utente.

Se stai lavorando da solo, l'aspetto della comunicazione non può essere che interessa a te, ma il test di integrazione si ottiene da cetriolo potrebbe essere. Se si prende vantaggio di Webrat , scrivendo cetriolo può essere veloce e indolore per un sacco di funzionalità di base.

Altri suggerimenti

Pensate a come un ciclo:

Scrivi la tua caratteristica cetriolo, poi sviluppando i pezzi per quella funzione, scrivere specifiche per completare i singoli componenti. Continuare completando specifiche fino a quando hai scritto abbastanza funzionalità per la funzione di passare, quindi scrivere la funzione successiva.

Il mio prendere è che è una cattiva idea di utilizzare cetriolo nella maggior parte delle situazioni a causa dei costi in termini di produttività sua sintassi è esposto per voi. Ho scritto ampiamente sul tema nella Perché perdere tempo con cetriolo I test?

Una storia cetriolo è più una descrizione del problema generale l'applicazione è risolvere, piuttosto che se singoli bit di lavoro codice (cioè unit test).

Come Abie descrive, è quasi un elenco di requisiti che l'applicazione deve soddisfare, ed è molto utile per la comunicazione con il cliente, oltre ad essere direttamente verificabile.

Al giorno d'oggi è possibile utilizzare RSpec con Capybara e selenio WebDriver ed evitare di dover costruire e mantenere tutti i parser storia cetriolo. Ecco quello che mi sento di raccomandare:

  1. Scrivi la tua storia
  2. Uso RSpec, vorrei creare un test di integrazione es: spec / integrazioni / socks_rspec.rb
  3. Poi vorrei creare un test di integrazione, che include una nuova descrivere e bloccare per ogni scenario
  4. Poi vorrei implementare la funzionalità minima richiedono per ottenere il test di integrazione e mentre andando più a fondo schiena (in controller e modelli, ecc) vorrei TDD sui controller e modelli.
  5. Come si arriva backup del test di integrazione deve passare ed è possibile continuare ad aggiungere misure per il test di integrazione
  6. ripetizione

Una cosa da notare, tuttavia, è che i test controller e di integrazione hanno sovrapposizioni che potrebbe non essere necessario, in modo da avere per utilizzare il vostro giudizio migliore in modo da non perdere tempo.

Inoltre, una volta a trovare la vostra scanalatura lo troverete più piacevole per sviluppare utilizzando BDD, fino a quel momento non si sentono in colpa se non ci si sente come si sta facendo perfetto e non più di pensate. Si farà grande!

  

Ma cosa succede se sto facendo il mio progetto? Per la maggior parte del tempo, so quanto le parti del sistema interagiscono. Tutto quello che devi fare è scrivere un po 'di unità di test. Quali sono le possibili situazioni in cui avrei bisogno di cetriolo allora?

Hai ancora bisogno di cetriolo. Avete bisogno di documentare come si vede il funzionamento del sistema, ed è necessario per assicurarsi che non hai rotto funzionalità quando si cambia le cose.

In altre parole, è necessario storie di cetriolo per le stesse ragioni di cui hai bisogno unit test -. Hanno appena lavorare su un alto livello di astrazione

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top