Quale dei due preferite per i test?
On 25 February 2011 08:47, Mauro [email protected] wrote:
Quale dei due preferite per i test?
Per gusto personale, rspec fa proprio al caso mio.
Devo prendere ancora le misure con cucumber ma per i test funzionali
proprio una figata
Ciao ciao
P
–
“… static analysis is fun, again!”
OWASP Orizon project leader, GitHub - thesp0nge/owasp-orizon: Owasp Orizon is a source code static analyzer tool designed to spot security issues in Java applications.
OWASP Esapi Ruby project leader,
GitHub - thesp0nge/owasp-esapi-ruby: The Owasp Esapi Ruby is a port for outstanding release quality Owasp Esapi project to the Ruby programming language. The idea is to build a Ruby gem (the standard ruby library archive format) containing the Esapi concepts implemented in Ruby classes so people using Ruby in their Rails application can have security into them.
On 25 February 2011 08:05, Paolo P. [email protected] wrote:
On 25 February 2011 08:47, Mauro [email protected] wrote:
Quale dei due preferite per i test?
Per gusto personale, rspec fa proprio al caso mio.
Devo prendere ancora le misure con cucumber ma per i test funzionali
proprio una figata
Usi anche autotest e spork?
Shoulda estato creato per usare BDD in progetti gia avviati, infatti
il codice puo` essere scritto direttamente nei Test Case. RSpec ha la
sua directory e non si integra come Shoulda.
Quindi RSpec per progetti nuovi a Shoulda per quelli avviati, anche se
nessuno ti vieta di usare Shoulda sempre. Shoulda ha dei matchers comodi
per testare le assoiciazioni, che RSpec non ha (anche se successivamente
sono stati con RSpec).
Alla fine preferisco RSpec perche` ha un suo libro, tanta documentazione
e spesso le librerie per il testing fanno vedere come possono essere
utilizzate con RSpec, poche con shoulda.
Una cosa che non mi epiaciuta di Shoulda e che hanno deprecato molte
librerie per testare il redirect dei controller (se mi ricordo bene),
dicendo che dovremmo usare Cucumber, cosa abbastanza discutibile.
Per quel che riguarda, sto creando delle API ed i test sui controller li
faccio
con RSpec, mentre per le viste ed un p di integration vorrei iniziare
con
steak
che ho guardato stamattina, sotto suggerimento 
Fare test del controller, forse inutile, ma ci sta, anche se pi volte
ho
pensato
che forse basterebbe fare un buon testing solo sulle viste.
2011/2/25 Nicholas W. [email protected]
On Feb 25, 2011, at 11:02 AM, Riccardo T. wrote:
e spesso le librerie per il testing fanno vedere come possono essere
utilizzate con RSpec, poche con shoulda.Una cosa che non mi e
piaciuta di Shoulda eche hanno deprecato molte
librerie per testare il redirect dei controller (se mi ricordo bene),
dicendo che dovremmo usare Cucumber, cosa abbastanza discutibile.
Eh …
Moltissimi, tra cui Hassox e wycats[1], sostengono che scrivere spec per
i controller sia un po’ come - and pardon my french - pulirsi il culo
con le stelle filanti. Totalmente inutile, insomma.
Da quel che so in EY non li scrivono affatto, ho avuto una discussione
(che forse possibile recuperare, non ne sono sicuro) sulla ML di warden
con hassox a riguardo.
Ammetto di essere pi dalla loro parte che dalla parte di chi testa lo
scibile umano - se chiamo un controller con i params x e y non mi
rassicura granch sapere che in effetti l’ho fatto e che n mocks poi
vengono chiamati con x e y piuttosto che con k e z - del resto quella
roba o l’ho scritta io, o abbastanza core, e posso permettermi di dare
per scontato che Rails e Ruby funzionano
Se ci pensi, nel momento in cui scrivi redirect_to :foo, che senso ha
testare che in effetti faccia il redirect ?
ngw
[1] wycats dovrebbe aver spiegato la sua posizione in qualche conferenza
su merb, io ormai sto invecchiando e non mi ricordo 
–
[ 926381, 23200231779, 1299022, 1045307475 ].collect { |a| a.to_s( 36 )
}.join( " " )
Nicholas W. (ngw)
[email protected]
io uso rspec per modelli e controller + steak e capybara per gli
integration. a
proposito, cosa preferite tra capybara e webrat? sembra che nessuno dei
due sia
completo, quello che manca a uno presente nell’altro
la discussione si sta facendo interessante 
ciao,
A.
Il 25/02/2011 12:29, Andrea R. ha scritto:
2011/2/25 Nicholas W.[email protected]
sono stati con RSpec).
Moltissimi, tra cui Hassox e wycats[1], sostengono che scrivere spec per i
Ruby funzionano
Se ci pensi, nel momento in cui scrivi redirect_to :foo, che senso ha
testare che in effetti faccia il redirect ?ngw
[1] wycats dovrebbe aver spiegato la sua posizione in qualche conferenza su
merb, io ormai sto invecchiando e non mi ricordo :
Il giorno 25 febbraio 2011 11:22, Nicholas W. [email protected] ha
scritto:
Moltissimi, tra cui Hassox e wycats[1], sostengono che scrivere spec per i
Ruby funzionano
Se ci pensi, nel momento in cui scrivi redirect_to :foo, che senso ha
testare che in effetti faccia il redirect ?
Premettendo che lo stesso discorso vale anche per le View, e che se
metti la
maggior parte della logica nei modelli (come dovrebbe essere, ma il
mondo
non perfetto) risolvi tutto con un bel test di integrazione (mettici la
tecnologia che vuoi, una questione di gusti, non di sostanza).
I test sui modelli servono per verificare i casi ‘edge’ che
probabilmente
faresti troppa fatica a verificare con test di integrazione (che
ricordiamo
sono in misura nettamente inferiore ai test unitari). Ovvio che se si ha
un’action particolarmente tosta forse il test unitario serve (come per
esempio se si deve gestire del caching spinto, ecc).
Io penso che bisogna andare per gradi, far passare il messaggio che “le
spec
sui controller non vanno fatte”, secondo me un errore nei confronti dei
newbies di TDD, BDD e di RoR in generale. Questo perch solo scrivendo le
spec dei controller (che sono odiose!) riesci a capire come puoi
strutturare
meglio la tua app: controller snelli e logica nei model. Solo a questo
punto
puoi “evitarti” di scriverli, a patto di fare dei test di integrazione
efficaci.
Ovviamente sono solo i miei 2 poveri centesimi.
Matteo
Matteo C. wrote in post #983886:
Io penso che bisogna andare per gradi, far passare il messaggio che “le
spec
sui controller non vanno fatte”, secondo me un errore nei confronti dei
newbies di TDD, BDD e di RoR in generale. Questo perch solo scrivendo le
spec dei controller (che sono odiose!) riesci a capire come puoi
strutturare
meglio la tua app: controller snelli e logica nei model.
Questo mi sento proprio di quotarlo: uno dei side effect talvolta
trascurati del TDD/BDD e’ quello di insegnarti a scrivere codice
applicativo pulito, chiaro negli intenti, atomico e comprensibile.
Ho visto controller fare di tutto di piu’, e la scusa era “io non testo
i controller, a cosa servono i test sui controller se devo scrivere 30
mock per poi alla fine testare l’evidenza…”
Scusate sono un newbbissimo, ma un controller non dovrebbe fare poco pi
(meglio poco che pi) del dispatch delle action sul Model? Tendendo conto
di
questo se si scrivono controller troppo complicati si dovrebbe capire da
se
che si sta facendo qualcosa di sbagliato? O mi sto confondendo?
2011/2/28 Andrea L. [email protected]
Questo mi sento proprio di quotarlo: uno dei side effect talvolta
[email protected]
http://lists.ruby-it.org/mailman/listinfo/ml
–
Mentre noi dormiamo, il dolore che sempre presente in noi cade goccia
a goccia sul nostro cuore, finch contro la nostra stessa volont, la
maestosa grazia di Dio non converte in saggezza la nostra disperazione
(ESCHILO)
L’esperienza quello che ottieni quando, non ottieni quello che
desideri.
On Friday, February 25, 2011 11:02:49 am Riccardo T. wrote:
Quindi RSpec per progetti nuovi a Shoulda per quelli avviati.
Idem.
Ciao
Flavio
Il giorno 28 febbraio 2011 10:46, Duncan [email protected] ha
scritto:
Scusate sono un newbbissimo, ma un controller non dovrebbe fare poco pi
(meglio poco che pi) del dispatch delle action sul Model? Tendendo conto
di
questo se si scrivono controller troppo complicati si dovrebbe capire da se
che si sta facendo qualcosa di sbagliato? O mi sto confondendo?
Tra il dire e il fare c’ di mezzo il mare :).
Tipicamente un newbie non riesce a seguire questa cosa, e non vede
l’errore
che commette seguendo l’approccio controller pesanti/model leggeri.
Scrivere
una spec di un controller pesante aiuta a vedere il problema.
Matteo
Il giorno 28 febbraio 2011 10:55, Nicholas W. [email protected] ha
scritto:
A me pare una contraddizione di termini se uno ha bisogno di scrivere
codice per capire di aver scritto troppo codice, ma tant’
Hai ragione, si chiama imparare “sbagliando”, e secondo me il miglior
modo
per apprendere. Fai una cavolata, ti accorgi di averla fatta e capisci
perch ti veniva detto di non farla.
Inoltre, credo sia insito nel TDD, poi non sono nessuno per dirlo :).
Matteo
A me pare una contraddizione di termini se uno ha bisogno di scrivere
codice per capire di aver scritto troppo codice, ma tant’ 
ngw
Il giorno 28 febbraio 2011 11:41, Duncan [email protected] ha
scritto:
Gi, in genere ci si rende conto di aver (scritto troppo codice)
abitudini sbagliate.
garantire il funzionamento dell’applicazione, non a scrivere bel codice,
magari
Dissento :D. Tipicamente il codice per essere testabile anche
correttamente disaccoppiato. Se non si scrivono test unitari…
tipicamente
viene fuori la classica matassa di spaghetti…
Matteo
On Feb 28, 2011, at 11:37 AM, Luigi P. wrote:
Il giorno 28/feb/2011, alle ore 10.55, Nicholas W. ha scritto:
A me pare una contraddizione di termini se uno ha bisogno di scrivere codice
per capire di aver scritto troppo codice, ma tant’Gi, in genere ci si rende conto di aver (scritto troppo codice) mescolato logica
di business e logica di interfaccia, solo dopo che l’applicazione cos piena di
codice frutto di cut&paste e “if” che una piccola richiesta di modifica alla
logica di business diventa una operazione da giorni e giorni di lavoro.
Oramai questo un antipattern di lavoro, dovuto come hanno detto altri ad
abitudini sbagliate.
Mah, per me abbastanza dura con Rails, a meno che il tappamento del
naso arrivi ad un fattore cronico ed esasperato (unito ad un notevole
disinteresse IMVHO). Ad un certo punto te ne accorgi davvero “ad
occhio”.
Anche il caching di cui si parlava, davvero poco furbo metterlo nei
controller, o stai cachando un dato, o stai cachando la rappresentazione
del dato.
Se nel controller l’unico motivo che posso eventualmente supporre una
qualche variabile di stato (come i vari logged_in? e similari), ma a
quel punto il problema di progettazione IMHO, e i test non ti aiutano
visto che la soluzione pi semplice la classica “separation of concerns”
a livello di viste (aka se nella stessa azione stai facendo due robe,
forse hai bisogno di due azioni, detta cos alla campagnola).
Poi non che siano inutili tout court, io semplicemente sostengo che
siano n volte meno utili di cucumber, infatti al momento ho una
tonnellata di stories e un numero decisamente inferiore di spec sul
controller (e 0 sul routing e 0 sulle request, visto che ci sono anche
quelle).
ngw
–
[ 926381, 23200231779, 1299022, 1045307475 ].collect { |a| a.to_s( 36 )
}.join( " " )
Nicholas W. (ngw)
[email protected]
2011/2/28 Luigi P. [email protected]
cos piena di codice frutto di cut&paste e “if” che una piccola richiesta di
Infatti, qui si vede l’uso della TDD, secondo me i test devono servire a
garantire il funzionamento dell’applicazione, non a scrivere bel codice,
magari 
Solitamente, dal progetto successivo si inizia a separare meglio quello che
va nei controller e quello che va nei modelli… da quello ancora successivo
si usa veramente il TDD… da quello ancora successivo si inizia a pensare
in modo OO, etc. etc.
Ml mailing list
[email protected]
http://lists.ruby-it.org/mailman/listinfo/ml
–
Mentre noi dormiamo, il dolore che sempre presente in noi cade goccia
a goccia sul nostro cuore, finch contro la nostra stessa volont, la
maestosa grazia di Dio non converte in saggezza la nostra disperazione
(ESCHILO)
L’esperienza quello che ottieni quando, non ottieni quello che
desideri.
Il giorno 28 febbraio 2011 14:33, Nicholas W. [email protected] ha
scritto:
piccola richiesta di modifica alla logica di business diventa una operazione
da giorni e giorni di lavoro.Oramai questo un antipattern di lavoro, dovuto come hanno detto altri
ad abitudini sbagliate.Mah, per me abbastanza dura con Rails, a meno che il tappamento del naso
arrivi ad un fattore cronico ed esasperato (unito ad un notevole
disinteresse IMVHO). Ad un certo punto te ne accorgi davvero “ad occhio”.
Sono d’accordo con te :). Ma purtroppo le brutte abitudini sono dure a
morire… e dipende dalla persona con cui stai parlando. Alcuni
sviluppatori
sono abbastanza svegli da voler migliorare, ad altri non importa. E
questi
ultimi sono, almeno in Italia, la maggioranza assoluta (non mi riferisco
agli sviluppatori Ruby, ovviamente, ma al totale complessivo).
Anche il caching di cui si parlava, davvero poco furbo metterlo nei
controller, o stai cachando un dato, o stai cachando la rappresentazione del
dato.
Se nel controller l’unico motivo che posso eventualmente supporre una
qualche variabile di stato (come i vari logged_in? e similari), ma a quel
punto il problema di progettazione IMHO, e i test non ti aiutano visto che
la soluzione pi semplice la classica “separation of concerns” a livello
di viste (aka se nella stessa azione stai facendo due robe, forse hai
bisogno di due azioni, detta cos alla campagnola).
Il caching che utilizzo nei controller quello HTTP, tramite l’uso di
stale?, expires_in, etag e compagnia bella. Come riesci a “tirarlo
fuori”
dal controller?
Poi non che siano inutili tout court, io semplicemente sostengo che siano
n volte meno utili di cucumber, infatti al momento ho una tonnellata di
stories e un numero decisamente inferiore di spec sul controller (e 0 sul
routing e 0 sulle request, visto che ci sono anche quelle).
Io quelle sul routing le scrivo… ho visto un paio di routes.rb
particolarmente incasinati, che se almeno avessero avuto un po’ di test
avrebbero semplificato notevolmente la mia opera di refactoring.
Su Cucumber sono d’accordo con te :).
Matteo