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

**URL:** <https://www.ruby-forum.com/t/bdd-steak-e-crud-ha-senso-testare-in-questo-modo/208462>\
**Category:** IT\
**Created:** [June 19, 2011, 10:28am UTC](https://www.ruby-forum.com/t/bdd-steak-e-crud-ha-senso-testare-in-questo-modo/208462 "2011-06-19T10:28:06Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![dubstep](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/cdc98d/32.png) [@dubstep](https://www.ruby-forum.com/u/dubstep)\
**Post date:** [June 19, 2011, 10:28am UTC](https://www.ruby-forum.com/t/bdd-steak-e-crud-ha-senso-testare-in-questo-modo/208462/1 "2011-06-19T10:28:06Z")

</div>

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](http://stefanoverna.com)

> **[weLaika](https://welaika.com/)**
>
> sito web di weLaika Società Cooperativa

---

<div class="post-metadata">

**Author:** ![steffoz](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/2bfe46/32.png) [@steffoz](https://www.ruby-forum.com/u/steffoz)\
**Post date:** [June 20, 2011, 10:35am UTC](https://www.ruby-forum.com/t/bdd-steak-e-crud-ha-senso-testare-in-questo-modo/208462/2 "2011-06-20T10:35:36Z")

</div>

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 😉

A.

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

---

<div class="post-metadata">

**Author:** ![steffoz](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/2bfe46/32.png) [@steffoz](https://www.ruby-forum.com/u/steffoz)\
**Post date:** [June 20, 2011, 10:44am UTC](https://www.ruby-forum.com/t/bdd-steak-e-crud-ha-senso-testare-in-questo-modo/208462/3 "2011-06-20T10:44:51Z")

</div>

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 😉  
> direi di s, grazie 🙂

---

<div class="post-metadata">

**Author:** ![steffoz](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/2bfe46/32.png) [@steffoz](https://www.ruby-forum.com/u/steffoz)\
**Post date:** [June 20, 2011, 11:01am UTC](https://www.ruby-forum.com/t/bdd-steak-e-crud-ha-senso-testare-in-questo-modo/208462/4 "2011-06-20T11:01:00Z")

</div>

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 😉

ciao,  
A.

---

<div class="post-metadata">

**Author:** ![steffoz](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/2bfe46/32.png) [@steffoz](https://www.ruby-forum.com/u/steffoz)\
**Post date:** [June 23, 2011, 9:52am UTC](https://www.ruby-forum.com/t/bdd-steak-e-crud-ha-senso-testare-in-questo-modo/208462/5 "2011-06-23T09:52:44Z")

</div>

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