BDD, Steak e CRUD: ha senso testare in questo modo?

Ciao,
per la prima volta ho avuto la possibilit di iniziare un progetto con
la traquillit di poter perdere qualche giornata ad imparare le basi di
uno sviluppo BDD. Dopo le prime ore con “sindrome da pagina bianca”, mi
sono messo di buona lena a provare a scrivere le prime storie con Steak.
Un esempio:

feature %q{
Creazione di nuove Agenzie

Per poter organizzare la contrattistica con i Promoter
Come responsabile
Voglio poter gestire Agenzie
} do

scenario ‘Creazione di nuove Agenzie’ do
visit new_agency_path

 test_fields_after_clicking_on "Crea Agenzia" do
   fill :text, :name, "Ragione sociale", "Test Agenzia"
   fill :text, :legal_representative_first_name, "Nome

rappresentante legale", “Stefano”
fill :text, :legal_representative_last_name, “Cognome
rappresentante legale”, “Verna”
fill :text, :vat_number, “P. IVA”, “12345”
fill :text, :phone_number, “Numero di telefono”, “12345”
fill :text, :notes, “Note”, “ABC”
and_expect_changes_on { Agency.first }
end

 page.should have_notice("Agenzia: creazione avvenuta con 

successo!")
end

scenario “Non possibile creare nuove Agenzie senza Ragione sociale”
do
visit new_agency_path
click_on “Crea Agenzia”
page.should have_alert(“Agenzia: errore durante la creazione!”)
page.should have_content(“Ragione sociale non pu essere lasciato
in bianco”)
end

end

Nel primo scenario potete vedere una DSL che, alla decima storia simile,
che ho costruito per rendere pi leggibile il codice. Fondamentalmente,
riempie i vari campi della pagina con il valore specificato, e dopo il
click al bottone del form controlla che gli attributi siano stati
effettivamente cambiati coerentemente su un qualche oggetto (in questo
caso, Agency.first).

Mi chiedevo se poteste darmi dei suggerimenti di vita vissuta da
utilizzare come “rules of thumb” nelle mie prossime avventure. Ci sono
dei controlli che avrebbe senzo fare magari a livello pi basso? Ci sono
degli scenari che avreste aggiunto? Ci sono cose che avreste spezzato su
pi scenari? Come avreste gestito voi la storia per una azione :create
del genere?

Grazie per il vostro aiuto!

Stefano V.

http://stefanoverna.com

una domanda: stai usando solo steak per i test, oppure hai scritto
anche i
vari unit test?

cos a occhio, direi che non c’ bisogno di scrivere un integration test
per
controllare che “non salva la nuova agenzia se manca la ragione sociale”
perch
un comportamento che potresti testare direttamente sul modello
“Agenzia”.
Invece, avrebbe molto senso se testassi che “l’utente viene
reindirizzato da
qualche parte
nel caso in cui ci sia un errore durante il salvataggio
di una
nuova agenzia”, oppure che “mostra il messaggio qualcosa quando
l’utente fa
click sul pulsante”

per gli scenari, trattandosi di “gestire le Agenzie” potresti verificare
ad alto
livello:

  • crea nuova agenzia
  • modifica agenzia
  • elimina agenzia
  • cosa accade in caso di errore (generico, ovviamente) durante
    creazione/modifica/eliminazione

per le operazioni a “basso livello” come la validazione sui modelli,
metodi e
callbacks particolari, dovresti scrivere appositi tests.

spero di esserti stato utile, se hai bisogno, chiedi pure :wink:

A.

Il 19/06/2011 10:27, Stefano V. ha scritto:

Ciao Andrea, grazie per il feedback!

una domanda: stai usando solo steak per i test, oppure hai scritto
anche i vari unit test?
s, sto testando anche controller e modelli. ho deciso di evitare di
testare le viste, considerando la presenza degli integration tests. mi
sembra una cosa ragionevole, no?
cos a occhio, direi che non c’ bisogno di scrivere un integration
test per controllare che “non salva la nuova agenzia se manca la
ragione sociale” perch un comportamento che potresti testare
direttamente sul modello “Agenzia”.
ok, in effetti lo testo anche l.
Invece, avrebbe molto senso se testassi che “l’utente viene
reindirizzato da qualche parte nel caso in cui ci sia un errore
durante il salvataggio di una nuova agenzia”, oppure che “mostra il
messaggio qualcosa quando l’utente fa click sul pulsante”
OK. Per il redirect, in realt i functional test sui controller
controllano gi i redirect in caso di errore o meno, quindi credo sia
superfluo a livello di integration, sbaglio? Quindi mi suggerisci pi
che altro di rinominare il secondo step in qualcosa tipo “Mostra
messaggi di errore in caso di mancata creazione”, mettendo in focus la
comunicazione all’utente pi che la validazione mancata su un attributo
piuttosto che un’altro, corretto?
per gli scenari, trattandosi di “gestire le Agenzie” potresti
verificare ad alto livello:

  • crea nuova agenzia
  • modifica agenzia
  • elimina agenzia
  • cosa accade in caso di errore (generico, ovviamente) durante
    creazione/modifica/eliminazione
    s, quello era uno snippet, ovviamente controllo anche la modifica e
    l’eliminazione.
    per le operazioni a “basso livello” come la validazione sui modelli,
    metodi e callbacks particolari, dovresti scrivere appositi tests.
    spero di esserti stato utile, se hai bisogno, chiedi pure :wink:
    direi di s, grazie :slight_smile:

Il 20/06/2011 10:44, Stefano V. ha scritto:

s, sto testando anche controller e modelli. ho deciso di evitare di testare le
viste, considerando la presenza degli integration tests. mi sembra una cosa
ragionevole, no?

si, credo che sia pi che ragionevole (ma sono gusti e/o dipende dalla
situazione)

OK. Per il redirect, in realt i functional test sui controller controllano gi
i redirect in caso di errore o meno, quindi credo sia superfluo a livello di
integration, sbaglio? Quindi mi suggerisci pi che altro di rinominare il
secondo step in qualcosa tipo “Mostra messaggi di errore in caso di mancata
creazione”, mettendo in focus la comunicazione all’utente pi che la validazione
mancata su un attributo piuttosto che un’altro, corretto?

in linea di massima, l’integration test qualcosa ad alto livello,
dovrebbe
verificare che i vari componenti dell’applicazione (gi testati
singolarmente)
funzionino correttamente. se vuoi, puoi vederla come un utente che usa
l’applicazione e/o una particolare feature dell’applicazione. tanto per
andare
con un esempio:

supponendo di voler testare la funzionalit di autenticazione,
sicuramente hai
gli unit-test sul modello Utente, probabilmente hai i functional sul
controller
Sessioni, ma con l’integration simuli un vero login :wink:

ciao,
A.

Concordo con i vostri ultimi due commenti. Io cercherei di non
accavallare troppo gli ambiti di ogni test perchè, im particolare su
grossi progetti, diventa onerosa la manutenzione.
Negli integration tests io solitamente verifico i messaggi applicativi
ossia il feedback che un utente dovrebbe avere. Se il record è stato
effettivamente affetto dall’operazione lo si controlla già con i
functional tests.

Detto questo, la verifica sulla creazione del primo messaggio non l’ho
capita (ma io a volte sono un pò tordo) non ti conviene farla sul numero
di records? Quel tipo ti test l’avrei pensato per l’update. Mi
piacerebbe capire questo.

Ciao
Marco