RSpec vs Cucumber (storie di RSpec) [chiuso]

Quando dovrei usare le specifiche per l'applicazione Rails e quando Cucumber (ex rspec-stories)? So come funzionano e utilizzano attivamente le specifiche, ovviamente. Ma è ancora strano usare Cucumber. La mia opinione attuale su questo, è che è conveniente usare Cucumber quando si implementa un'applicazione per il client e non capisco come dovrebbe funzionare l'intero sistema.

Ma cosa succede se sto facendo il mio progetto? Per la maggior parte del tempo, so come interagiscono le parti del sistema. Tutto quello che devo fare è scrivere un sacco di test unitari. Quali sono le possibili situazioni in cui avrei bisogno di Cetriolo allora?

E, come seconda domanda corrispondente: devo scrivere le specifiche se scrivo storie su Cetriolo? Non sarebbe un doppio test della stessa cosa?

Se non l'hai già fatto, potresti dare un'occhiata all'eccellente articolo di Dan North, What's in a Story? come punto di partenza.

Abbiamo due usi principali per le storie di Cucumber. Innanzitutto, poiché la forma della trama è molto specifica, aiuta a focalizzare l'articolazione del proprietario del prodotto sulle funzionalità che desidera creare. Questo è il "token per una conversazione" di utilizzo delle storie, e sarebbe utile se le storie fossero implementate o meno nel codice. In secondo luogo, quando il processo sta funzionando abbastanza bene da avere storie complete prima di iniziare a scrivere la funzione (più di un ideale per cui ci battiamo che una realtà quotidiana), hai i tuoi criteri di accettazione spiegati chiaramente e sai esattamente cosa e come molto da costruire.

Nel nostro lavoro su Rails, le storie di Cucumber non sostituiscono i test unitari rspec. I due vanno mano nella mano. In pratica, i test unitari tendono a guidare lo sviluppo dei modelli e dei controller e le storie tendono a guidare lo sviluppo delle viste (tendiamo a non scrivere rspec per le nostre opinioni) e forniscono un buon test dell'applicazione nel suo insieme dal prospettiva dell'utente.

Se lavori da solo, l'aspetto della comunicazione potrebbe non essere così interessante per te, ma potrebbe essere il test di integrazione che ricevi da Cucumber. Se usi Webrat , scrivere Cucumber può essere veloce e indolore per molte delle tue funzionalità di base.

Pensalo come un ciclo:

Scrivi la tua funzione Cetriolo, quindi mentre sviluppi i pezzi per quella funzione, scrivi le specifiche per completare i singoli componenti. Continua a completare le specifiche fino a quando non avrai scritto funzionalità sufficienti per il passaggio della funzione, quindi scrivi la funzione successiva.

La mia opinione è che è una cattiva idea usare Cucumber nella maggior parte delle situazioni a causa dei costi di produttività che la sua sintassi comporta per te. Ho scritto ampiamente sull'argomento in Perché perdere tempo con i test sui cetrioli?

Una storia di Cucumber è più una descrizione del problema generale che la tua applicazione sta risolvendo, piuttosto che se i singoli bit di codice funzionano (cioè test unitari).

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

Oggi puoi usare rspec con Capybara e Selenium Webdriver ed evitare di dover costruire e mantenere tutti i parser della storia di Cucumber. Ecco cosa consiglierei:

1. Scrivi la tua storia
2. Usando RSpec, vorrei creare un test di integrazione ex: spec / integrations / socks_rspec.rb
3. Quindi vorrei creare un test di integrazione che includa una nuova descrizione e blocchi per ogni scenario
4. Quindi implementerei le funzionalità minime necessarie per ottenere il test di integrazione e andando più a fondo (in controller e modelli, ecc.) TDD su controller e modelli.
5. Al ritorno, il test di integrazione dovrebbe superare e puoi continuare ad aggiungere passaggi al test di integrazione
6. ripetere

Una cosa da notare, tuttavia, è che i test del controller e dell'integrazione si sovrappongono e potrebbero non essere necessari, quindi è necessario utilizzare il proprio giudizio in modo da non perdere tempo.

Inoltre, una volta trovato il tuo groove troverai più divertente svilupparti usando BDD, fino ad allora non sentirti in colpa se non ti senti come se lo stessi facendo perfettamente e non ci pensi oltre. Farai alla grande!

Ma cosa succede se sto facendo il mio progetto? Per la maggior parte del tempo, so come interagiscono le parti del sistema. Tutto quello che devo fare è scrivere un sacco di test unitari. Quali sono le possibili situazioni in cui avrei bisogno di Cetriolo allora?

Hai ancora bisogno del cetriolo. Ne hai bisogno per documentare come vedi il sistema funzionare e ti serve per assicurarti di non aver rotto la funzionalità quando cambi le cose.

In altre parole, hai bisogno delle storie di Cetriolo per le stesse ragioni per cui hai bisogno di unit test: funzionano solo su un livello più alto di astrazione.