Forum: Italian Ruby user group integration test, cucumber o cosa?

Ho dei problemi seri con gli integration test. Cucumber mi sta un p 
antipatico, per il suo proponimento
di tradurre l'inglese in test. Potrebbe darsi che la mia avversit 
dipenda dal fatto che non l'ho mai approfondito
a livelli tali da diventare produttivo come dico io.

Pertanto ho in programma di dedicare del tempo al rispolvero degli 
integration test in generale.

Quindi piccolo sondaggio. Che cosa usate per gli integration test, 
cucumber, rspec requests, o che altro?

+1 per Capybara + Rspec


2013/1/25 Fabrizio Regini <freegenie@gmail.com>

> cucumber, rspec requests, o che altro?
>
>
> _______________________________________________
> Ml mailing list
> Ml@lists.ruby-it.org
> http://lists.ruby-it.org/mailman/listinfo/ml
>



--
Andrea Reginato
Lelylan | reThink your house
http://lelylan.com

2013/1/25 Fabrizio Regini <freegenie@gmail.com>:
> Ho dei problemi seri con gli integration test. Cucumber mi sta un p antipatico, 
per il suo proponimento
> di tradurre l'inglese in test.

Non sei l'unico:-)  Mi sembra una di quelle idee anni 70 che sono
fallite orribilmente, ma che continuano ad essere riproposte.

--
David N. Welton

http://www.welton.it/davidw/

http://www.dedasys.com/

Il giorno 25 gennaio 2013 20:45, David Welton <davidnwelton@gmail.com> 
ha
scritto:

> 2013/1/25 Fabrizio Regini <freegenie@gmail.com>:
> > Ho dei problemi seri con gli integration test. Cucumber mi sta un p
> antipatico, per il suo proponimento
> > di tradurre l'inglese in test.
>
> Non sei l'unico:-)  Mi sembra una di quelle idee anni 70 che sono
> fallite orribilmente, ma che continuano ad essere riproposte.


Il bello di cucumber  che ti forza a pensare per "step", e penso sia il
modo giusto per implementare
gli integration test. Gli "step" devono avere uno scopo ben preciso, 
chiaro
dal nome.

Detto questo, se codifichi i tuoi step in metodi/funzioni/vattelapesca 
va
bene uguale, che sia inglese,
ruby o un linguaggio che ti inventi tu.
L'importante nei test di integrazione  non avere "tutto il codice tutto
assieme", perch la manutenibilit
di quella soluzione  bassissima: capire cosa faceva quel test, gestire 
la
duplicazione del codice (che nei
test di integrazione  altissima), ecc.. dopo un po' fa prendere la
decisione "mandiamo la suite di test a puttane".
Una soluzione equivalente  RSpec con gli step codificati in un modulo.

Ciao,

Matteo

Cucumber immagino acquisti un valore in progetti nei quali gli 
stakeholders
effettivamente contribuiscano alla realizzazione di stories. La suite di
integration Cucumber in quel caso potrebbe essere un ottimo mezzo per
comunicare lo stato di avanzamento dei lavori, in grado di essere 
compreso
non solo dai programmatori ma anche da tutti gli altri personaggi 
coinvolti
nello sviluppo.

Nel caso in cui non ci siano queste condizioni (ovvero il 99.999% dei
progetti in Italia), tradurre in inglese passando per regular-expression
diventa solo una tremenda noia senza valore aggiunto.

imho, ovviamente.

2013/1/26 Matteo Collina <matteo.collina@gmail.com>

Ho avuto la fortuna di lavorare in un team con una persona molto esperta 
di cucumber,
In team di cui facevano parte un programmatore ios e un front end 
developer che lavorava
con backbone.

Tutto quello che dici  vero, cucumber ha funzionato benissimo. Le 
features testuali erano
molto apprezzate (descrivevano delle API nel nostro caso) dai due 
programmatori che non
masticavano Ruby e lo sviluppo  andato velocissimo e le features erano 
un vero e proprio
fulcro. La funzionalit c'era se qualcuno poteva leggere un feature file, 
altrimenti la feature
non esisteva. Tutti controllavano gli aggiornamenti della cartella 
features.

Per ho riscontrato anche parecchia complessit nella stesura dei file 
stessi, spesso svariate
scatole cinesi di definizioni in cui era difficile orientarsi, quindi 
penso sia questo il prezzo da
pagare.

Sono anche d'accordo con Matteo sul fatto che scrivere gli integration 
in rspec fa ricadere molto pi su di te la
responsabilit di scrivere i test in modo intelligente, per non duplicare 
il codice e per non mettere troppo in
un unico test.

Boh, penso che l'approccio migliore sia investire in cucumber se pensi 
che ti servir in un team
per cui quel tipo di documentazione ha valore.

Quello che faccio ultimamente :
* Testare con Mock, OpenStruct, FactoryGirl.build_stubbed (isolation), i
controllers, models, views ed helpers (spec/*).
* Testare con Jasminerice le piccole "classi" JS.
* Testare con FactoryGirl.create le classi di servizio
(spec/integration/account_migrator_spec.rb), dove ho la necessit di 
creare
un po' di records che devono interagire tra di loro, ma non  richiesta 
la
simulazione con un utente.
* Testare con Capybara + RSpec (spec/features/user_login_spec.rb) come
rimpiazzo di Cucumber.

Cucumber ha l'unico vantaggio di essere un bridge con gli stakeholders.
Ora, in tutta la mia carriera, ho sempre scritto io gli scenari, per cui 
mi
son reso conto che non ha senso avere features scritte in prosa inglese, 
se
poi sono solo i programmatori ad usufruire di questo strumento.

Inoltre Cucumber pretende una forma inglese, che non sempre ha senso per
quello che vogliamo esprimere. Vi  mai capitato di avere degli step 
vuoti
(quindi superflui), solo per "accontentare" Cucumber? Oppure dover
specificare il business value di un login?

RSpec non ha una forma rigida, quindi  facile che gli scenari diventino
presto illegibili. La mia soluzione a questo problema  quella di
implementarli come una lista di invocazione a dei metodi che dichiarino 
un
intento (di azione o asserzione).

Ecco un esempio funzionante: 
https://gist.github.com/eb8379a8969ec3b5c1d9

Buona domenica e buon coding!
Luca


2013/1/26 Fabrizio Regini <freegenie@gmail.com>

Interessante, Luca, grazie per il gist :)
Hai dato un occhio a Spinach[1]? Vedo delle somiglianze col tuo 
approccio
:)

[1]: http://codegram.github.com/spinach/readme.html

2013/1/27 Luca Guidi <guidi.luca@gmail.com>

Si, conosco Spinach, ma non l'ho mai usato, perch non ne ho mai avuto
l'occasione. Ora che RSpec ha tutta questa potenza, mi sembra inutile 
avere
un'altra dipendenza da libreria esterna.

Luca


2013/1/27 Stefano Verna <stefano.verna@welaika.com>

concordo :) tra l'altro segnalo rspec-given[1] che permette di usare le
keyword Given/When/Then in Rspec.

[1]: https://github.com/jimweirich/rspec-given

2013/1/27 Luca Guidi <guidi.luca@gmail.com>

Grazie Luca, sono molto contento che l'approccio a helper abbia 
sostenitori,
Tra l'altro il gist  chiarissimo.

Ho usato in passato Cucumber per supportare lo sviluppo di API REST,
in modo da poter comunicare efficacemente con i dev mobile.
In pratica non c' stato bisogno di spiegargli le API, lo strumento ha
funzionato
benissimo.

Ultimamente ho usato https://github.com/square/fdoc per gestire la 
stessa
parte.
In effetti funziona meglio per spiegare/validare i JSON, ma peggio per
gestire il "flusso"
dell'app.
Dal momento che  basato su RSpec, pu essere combinato con l'approccio
descritto cos bene da Luca, facendone una "combo" interessante.

Ciao,

Matteo


Il giorno 27 gennaio 2013 10:30, Luca Guidi <guidi.luca@gmail.com> ha
scritto:

qualcuno ha provato steak?
https://github.com/cavalle/steak

Il 27 gennaio 2013 13:04, Matteo Collina <matteo.collina@gmail.com> ha 
scritto:

Ciao Michele, steak  stato "assorbito" da Rspec! :)
https://www.relishapp.com/rspec/rspec-rails/v/2-12...

2013/1/27 Michele Franzin <michele@franzin.net>

Il 27 gennaio 2013 15:08, Stefano Verna <stefano.verna@welaika.com> ha 
scritto:
> Ciao Michele, steak  stato "assorbito" da Rspec! :)
> 
https://www.relishapp.com/rspec/rspec-rails/v/2-12...

Thnx, me l'ero perso... information overflow. Ecco spiegato il perch
il codice me lo ricordava tanto :-)

Come hanno detto in molti Cucumber serve per comunicare con gli 
stakeholders ma serve anche come 'living documentation'. Usare Cucumber 
quando si e` da soli serve a poco, giusto ad organizzare le idee. Usare 
Capybara + RSpec con le descrizioni in stile Cucumber lo trovo 
ripetitivo, l'ho usato con convinzione poi mi hanno fatto notare che la 
parte in inglese non era altro che una copia del codice scritto con 
Capybara e visto che l'unico stakeholder non li leggeva, mi son reso 
conto che potevo lasciar perdere.

Al di la dello sviluppo web Cucumber puo` essere utilizzato per 
sviluppare e tesare infrastrutture usando BDD: 
http://www.cucumber-chef.org/. Si possono testare anche app per iPhone 
oppure applicazioni desktop.

Inoltre non siete obbligati ad usare l'inglese, c'e` anche l'italiano 
disponibile.

Riccardo,
 tutta questione di leggibilit del codice.

Article.where('articles.published_at IS NOT
NULL').order('articles.published_at DESC').limit(5)
#vs
Article.most_recent_published

I metodi sono equivalenti dal punto di vista del comportamento, ma il
secondo esprime un intento, il primo no.

Cos come avere un helper `login_as`, rispetto ad avere la sua
implementazione<https://gist.github.com/eb8379a8969ec3b5c1d9#file-...
 inline.

Luca






2013/1/28 Riccardo Tacconi <rtacconi@gmail.com>

ripesco la conversazione.

ho trovato questa gemma che segue un approccio molto simile a quello di 
Luca:

https://github.com/robb1e/simple_bdd

c' anche un articolo dei suoi autori, decisamente interessante:

http://pivotallabs.com/thoughts-on-simple-bdd/


ciao,
A.




Il giorno 28/gen/2013, alle ore 10:11, Luca Guidi <guidi.luca@gmail.com> 
ha scritto:

>
>
>>
>> _______________________________________________
> Ml mailing list
> Ml@lists.ruby-it.org
> http://lists.ruby-it.org/mailman/listinfo/ml

--
http://andreapavoni.com

Ripesco il thread per dire che ultimamente, eliminando cucumber da
un'applicazione, mi sono trovato bene con bbq[1] + rspec per i test di
integrazione.

Cucumber andava stretto all'applicazione in questione: il grosso dei
test, infatti, riguarda l'interazione tra più utenti e la scrittura di
feature sensate diventava davvero difficoltosa. bbq mi ha aiutato
perché ad ogni sessione utente corrisponde un'istanza facilmente
utilizzabile e leggibile nei test. Il codice risultante somiglia a:

  it 'carlo should receive a notification from barbara' do
    person_carlo.visit_new_user_session_page
    person_carlo.do_login('carlo')
    person_barbara.visit_new_user_session_page
    person_barbara.do_login('barbara')
    person_barbara.see!('alice ha iniziato a seguirti')
  end

[1]: https://github.com/drugpl/bbq

Ciao,
Silvano



2013/4/3 Andrea Pavoni <apeacox@gmail.com>:
>
>>
>> inline.
>>> Come hanno detto in molti Cucumber serve per comunicare con gli
>>> http://www.cucumber-chef.org/. Si possono testare anche app per iPhone
>>> http://lists.ruby-it.org/mailman/listinfo/ml
>
> --
> http://andreapavoni.com
>
>
>
> _______________________________________________
> Ml mailing list
> Ml@lists.ruby-it.org
> http://lists.ruby-it.org/mailman/listinfo/ml



--
Considera l'ambiente prima di stampare questa email. Be a total user
rather than a complete waster.


. . . Silvano Stralla . . .
❡ email: silvano.stralla@sistrall.it
❡ site: http://www.sistrall.it
★ future: http://contiamoci.com/
★ kitchen: http://keepcooking.it/

David Welton wrote in post #1093811:

> Non sei l'unico:-)  Mi sembra una di quelle idee anni 70 che sono
> fallite orribilmente, ma che continuano ad essere riproposte.

La combinazione cucumber + relishapp (https://www.relishapp.com/)  è
imho molto interessante, perché permette di scrivere test che diventano
documentazione navigabile sul browser. Un esempio che probabilmente
molti conoscono è https://www.relishapp.com/rspec