Il mio 'ah-ha!' i momenti di test su Ruby e Rails sono arrivati quando mi sono seduto e ho letto le risorse definitive sull'argomento, il Rspec e Cetriolo libri. Ho condiviso il tuo disprezzo iniziale di Cetriolo, ma poi mi sono reso conto che stavo guardando l'immagine dall'angolo sbagliato.
Fondamentalmente, Cucumber riguarda BDD (sviluppo guidato dal comportamento) - usi Cucumber per pianificare le tue funzionalità, su cosa lavorerai in seguito. Hmm, dopo vuoi che gli utenti siano in grado di promuovere post su un forum o qualcosa del genere (per rubare un esempio;)) Quindi scrivi qualcosa di semplice.
Given I am logged in
And I can see the post "BDD is awesome"
When I vote the post up
Then the post should have one more vote
And the page should show a message thanking me for my vote.
Si noti che non ci sono riferimenti a qualsiasi cosa relativa al codice in questo campo. Questo viene nei tuoi passi. Quando si effettua il refactoring del codice, potrebbe essere necessario modificare le definizioni dei passaggi, ma il comportamento (la funzionalità) non dovrà mai essere modificato.
Ora, ogni volta che esegui la funzione Cucumber, ti verrà praticamente spiegato come testare la funzione utilizzando TDD (sviluppo basato su test). Questo viene fatto a un livello inferiore usando RSpec.
Prima esecuzione: la mia prima definizione di passo non è definita. Copia il blocco per definirlo in user_steps.rb o anche session_steps.rb perché si riferisce agli utenti e alle loro sessioni. Ora, come si definisce che un utente abbia effettuato l'accesso? Puoi portarli attraverso il processo di accesso.
Given /^I am logged in$/ do
visit login_path
fill_in :name, :with => 'Joe'
fill_in :password, :with => 'Password'
click_button 'submit'
end
Dovrebbe essere tutto felice. Secondo passo.
Given /^I can see the post "(.+)"$/ do |name|
visit post_path(Post.find_by_name(name))
end
Di nuovo abbastanza facile. Tieni presente che se ripristiniamo completamente la nostra procedura di accesso, o come vengono definiti e mostrati i nostri post, non dobbiamo modificare il comportamento. Terzo passo.
When /^I vote the post up$/ do
pending
end
Ecco dove stai iniziando a parlare di nuove funzionalità, ma non sai ancora come funzionerà. Come vota un post? È possibile fare clic su un'immagine di un +1 o qualcosa, che fa un post ajax su un controller, che restituisce JSON, o qualcosa di simile. Quindi ora puoi passare al puro test Rspec.
- Verifica la tua vista per assicurarti che l'immagine +1 sia visualizzata,
- Verifica il controller in modo che si comporti correttamente quando riceve una determinata richiesta Ajax del formato corretto (entrambi i percorsi felici e infelici - cosa succede se viene ricevuto un ID post non valido? Cosa succede se l'utente ha esaurito i suoi 25 upvotes in un giorno? Aumenta correttamente il numero di voti?)
- Verifica il tuo javascript che risponda correttamente quando viene fornito un blob di JSON nel formato corretto (aggiorna l'immagine +1 per mostrare che è stato usato? (pensando a Google+ qui ...) Mostra il messaggio di ringraziamento ? ecc.)
Tutto ciò non influisce sul comportamento, ma quando hai finito di occuparti del test di livello inferiore, sarà banale compilare la definizione del passo su come votare un post. Potrebbe essere semplice come click_link '+1' . E il resto dei passaggi sta testando i risultati, che dovrebbe essere di nuovo semplice da fare. E quando hai finito, allora sai che la tua funzione è completa e finita. Se il comportamento necessario cambia, puoi modificare la tua funzionalità, altrimenti puoi modificare il codice di implementazione in perfetta sicurezza.
Spero che abbia senso. È stato tutto fuori di testa, ma penso che dimostri la differenza tra BDD e TDD, e perché Cucumber e RSpec soddisfino esigenze diverse.