Cucumber è semplicemente un wrapper attorno a rspec per aiutare a organizzare i test nelle funzionalità?

Question

Voglio solo assicurarmi di capire le cose.

Da quanto ho capito finora, Cucumber è semplicemente un 'wrapper' o un modo carino per organizzare i test classificando le cose in funzioni e fasi, dove i test unitari effettivi sono nella fase dei passaggi.

Permette di organizzare i test su come funzionano le cose.

È corretto?

Answer 1

Sort of.

It è un modo per organizzare i test, ma è più di quello. Si comporta come i test di integrazione originali di Rails, ma è molto più facile da usare. La grande vittoria qui è che la tua sessione viene mantenuta in modo trasparente nell'intero Scenario.

Un'altra cosa che sta succedendo con Cucumber è che si è (si presume che siano) test dal punto di vista di un browser o di un client che utilizza il proprio codice. Se vuoi, puoi usare i passaggi per creare oggetti e impostare lo stato, ma di solito vuoi che i tuoi passi seguano i movimenti richiesti per raggiungere quello stato in primo luogo.

Per esempio si potrebbe fare questo:

Given /I have a user account/ do 
    @user = Factory.create(:user) 
    # ... more user set up 
end 

Ma probabilmente si dovrebbe fare qualcosa di simile a questo, invece:

Given /I have a user account/ do 
    visit new_user_url 
    fill_in "user_login", :with => "some name" 
    fill_in "user_password", :with => "foo" 
    # ... whatever else your sign up page needs 
end 

E naturalmente è possibile passare in argomenti per uno di quei passi per dare al codice chiamante un controllo più preciso sul comportamento del passo.

Quello che ho generalmente fatto con i miei test è il seguente.

1. Io uso shoulda, ma anche rspec va bene.
2. Scrivo i miei test di autorizzazione negativa (ad esempio, Accesso negato è previsto) come test funzionali di Rails.
3. Scrivo i miei test di autenticazione positiva (ovvero, gli utenti fanno ciò che dovrebbero fare) come funzioni di Cucumber.

E, naturalmente, ho ancora scrivere Rails unit test per i miei modelli, biblioteche, aiutanti, ecc

Answer 2

mi piace cetriolo perché descrive quello il comportamento è senza descrivere come è implementato. Cucumber disaccoppia sostanzialmente la specifica (che è anche un test di accettazione/regressione eseguibile) dall'implementazione. Le definizioni di passo sono l'adattatore tra la specifica e il sistema in prova, che abilita il disaccoppiamento.

Si può anche affermare che Cucumber fornisce una specifica più leggibile da umani rispetto a RSpec o altre sintassi basate su Ruby, che possono essere comprese (anche scritte) da un client non programmatore.

Answer 3

Direi che la tua comprensione è errata.

I test di unità e di cetriolo sono completamente diversi e in gran parte cose non correlate.

Cetriolo I test sono combinazione test di integrazione/accettazione utente e come tali devono essere indipendenti dall'attuale implementazione nel codice. Quindi, in teoria, potresti riscrivere completamente la tua app in una lingua diversa e i tuoi test di cetriolo e i possibili passaggi dovrebbero comunque essere utili, assumendo che tu non abbia cambiato il comportamento delle tue applicazioni. I test unitari d'altra parte sono intimamente legati al codice, testando cose come i valori di ritorno di chiamate di metodi specifici, casi limite relativi a strutture di dati, ecc. Modifica un metodo e devi cambiare il tuo test unitario.

Ci sono alcuni buoni screencast che parlano di usare Cucumber e RSpec per costruire/testare la tua app dall'esterno. Qui ci sono pochi che dovrebbero aiutarti a iniziare migliorare la comprensione di come test di integrazione e test di unità può andare bene insieme:

http://blog.josephwilk.net/ruby/outside-in-development-with-cucumber-and-rspec.html

http://rubyconf2008.confreaks.com/rspec-and-cucumber.html

http://confreaks.net/videos/72-mwrc2009-bdd-with-cucumber

mio uso personale di cetriolo è un È un po 'eretico perché spesso uso solo cetrioli su progetti più piccoli, in quanto sostituisce la monotonia di script di esecuzione e di riesecuzione che non sono abbastanza importanti per eseguire lo sviluppo completo basato su test di unità. Questo comunque non è sicuramente il consenso della comunità (almeno in pubblico) su come fare le cose.

Answer 4

Cucumber non è un wrapper su RSpec. RSpec è uno strumento utilizzato per guidare il codice a livello di unità (una classe alla volta) mentre cetriolo è uno strumento per definire le funzionalità del sistema che sono a loro volta automatizzate.

Le specifiche RSpec vengono in genere scritte una alla volta mentre il codebase si evolve. Specifichiamo il prossimo piccolo comportamento della classe che stiamo attualmente scrivendo.

Contrasto che a Cucumber dove scriviamo un set di scenari che non sono altro che un esempio di come il sistema verrà utilizzato da un utente finale. Generalmente la maggior parte degli Scenari vengono scritti prima dell'inizio dello sviluppo e servono allo scopo di definire quale funzionalità deve contenere la funzionalità. In un ambiente Agile, una funzionalità è considerata funzionalmente completa quando passano tutti gli Scenari.

Nei negozi più piccoli gli sviluppatori scrivono sia le caratteristiche/scenari di Cucumber che le specifiche RSpec. Nei negozi più grandi queste attività sono suddivise tra gli sviluppatori che scrivono le specifiche mentre i proprietari e i tester del prodotto scrivono e automatizzano gli scenari.