Integration test, cucumber o cosa?

aris · January 25, 2013, 8:55pm

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?

fregini · January 25, 2013, 9:28pm

+1 per Capybara + Rspec

2013/1/25 Fabrizio R. [email protected]

cucumber, rspec requests, o che altro?

Ml mailing list
[email protected]
http://lists.ruby-it.org/mailman/listinfo/ml

–
Andrea R.
Lelylan | reThink your house
http://lelylan.com

fregini · January 25, 2013, 9:45pm

2013/1/25 Fabrizio R. [email protected]:

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/

fregini · January 26, 2013, 2:17pm

Il giorno 25 gennaio 2013 20:45, David W. [email protected]
ha
scritto:

2013/1/25 Fabrizio R. [email protected]:

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

fregini · January 26, 2013, 4:14pm

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 C. [email protected]

fregini · January 26, 2013, 9:19pm

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.

fregini · January 27, 2013, 11:30am

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:

gist.github.com

https://gist.github.com/jodosha/eb8379a8969ec3b5c1d9

account_management_helpers.rb

# -*- encoding : utf-8 -*-

# spec/support/features/helpers/account_management_helpers.rb

module Features
  module Helpers
    module AccountManagementHelpers
      private
      def when_visit_account_page
        visit account_path(@account)

This file has been truncated. show original

login_helpers.rb

# -*- encoding : utf-8 -*-

# spec/support/features/helpers/login_helpers.rb

module Features
  module Helpers
    module LoginHelpers
      def login_as(user, password = 'secret')
        visit login_path

This file has been truncated. show original

manage_account_spec.rb

# -*- encoding : utf-8 -*-

# spec/features/manage_account_spec.rb

require 'spec_helper'

feature 'Account holder manages account' do
  include Features::Helpers::AccountManagementHelpers

  background do

This file has been truncated. show original

There are more than three files. show original

Buona domenica e buon coding!
Luca

2013/1/26 Fabrizio R. [email protected]

fregini · January 27, 2013, 11:40am

Interessante, Luca, grazie per il gist
Hai dato un occhio a Spinach1? Vedo delle somiglianze col tuo
approccio

2013/1/27 Luca G. [email protected]

fregini · January 27, 2013, 12:48pm

concordo tra l’altro segnalo rspec-given1 che permette di usare le
keyword Given/When/Then in Rspec.

2013/1/27 Luca G. [email protected]

fregini · January 27, 2013, 12:22pm

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 V. [email protected]

fregini · January 27, 2013, 1:05pm

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 GitHub - square/fdoc: Documentation format and verification 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 G. [email protected] ha
scritto:

fregini · January 27, 2013, 2:59pm

qualcuno ha provato steak?

Il 27 gennaio 2013 13:04, Matteo C. [email protected] ha
scritto:

fregini · January 27, 2013, 3:09pm

Ciao Michele, steak stato “assorbito” da Rspec!
https://www.relishapp.com/rspec/rspec-rails/v/2-12-2/docs/feature-specs/feature-spec

2013/1/27 Michele F. [email protected]

fregini · January 28, 2013, 10:00am

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.

fregini · January 28, 2013, 10:11am

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
implementazionehttps://gist.github.com/eb8379a8969ec3b5c1d9#file-login_helpers-rb
inline.

Luca

2013/1/28 Riccardo T. [email protected]

fregini · April 3, 2013, 6:59pm

ripesco la conversazione.

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

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 G. [email protected]
ha scritto:

Ml mailing list
[email protected]
http://lists.ruby-it.org/mailman/listinfo/ml

–

fregini · January 27, 2013, 3:14pm

Il 27 gennaio 2013 15:08, Stefano V. [email protected] ha
scritto:

Ciao Michele, steak stato “assorbito” da Rspec!

https://www.relishapp.com/rspec/rspec-rails/v/2-12-2/docs/feature-specs/feature-spec

Thnx, me l’ero perso… information overflow. Ecco spiegato il perch
il codice me lo ricordava tanto

fregini · April 16, 2013, 11:54pm

David W. 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

fregini · April 16, 2013, 6:00pm

Ripesco il thread per dire che ultimamente, eliminando cucumber da
un’applicazione, mi sono trovato bene con bbq1 + 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

Ciao,
Silvano

2013/4/3 Andrea P. [email protected]:

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
[email protected]
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 S. . . .
❡ email: [email protected]
❡ site: http://www.sistrall.it
★ future: http://contiamoci.com/
★ kitchen: http://keepcooking.it/