Forum: Italian Ruby user group Come fate il testing ?

0d4857c0bd9540f743afc22758a06c46?d=identicon&s=25 FleX (Guest)
on 2013-10-20 16:46
(Received via mailing list)
Ciao,

mi rendo conto che la domanda puo' sembrare banale, ma non riesco a
trovare un workflow convincente. Attualmente faccio cosi':

1) Creo i model
2) Scrivo gli unit test per i model (usando shoulda + factory girls)

3) scrivo i test funzionali per i controller
4) modifico il codice finche' non diventano tutti verdi eventualmente
applicando il refactoring

5) scrivo ed eseguo gli integration test (usando Capibara) che si
integrano con tutto il codice scritto in precedenza

A parte la grande difficolta' che ho nel completare il punto 3 prima di
iniziare il 4, c'e' qualcosa di sbagliato/migliorabile ?

--
FleX
[Linux User #347703 PGP Key ID: 98AA9D3E
FingerPrint: 7D25B 0CE4 898A 22CB F765  E2A5 88B7 4C5C 98AA 9D3E]
4f4122bc3b9999d9050f0b1a10b63251?d=identicon&s=25 Andrea Reginato (reis)
on 2013-10-21 00:38
(Received via mailing list)
Evita i test sui controller. Per quel che mi riguarda, duplicano le
funzionalit
degli integration test. Una discussiono a riguardo la trovi
qui<http://betterspecs.org/#integration>
.


2013/10/20 FleX <flex@programmareweb.com>

> applicando il refactoring
> FingerPrint: 7D25B 0CE4 898A 22CB F765  E2A5 88B7 4C5C 98AA 9D3E]
> _______________________________________________
> 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
5ce16d85034e08079db3cafeb5b8ff09?d=identicon&s=25 Davide Rambaldi (Guest)
on 2013-10-21 10:09
(Received via mailing list)
La soluzione e' non fare i test!

I test sono per i deboli!

Per un workflow convincente:

http://gradha.sdf-eu.org/textos/klingon_programmer.en.html

(lo so mi ripeto)

Ciao
0d4857c0bd9540f743afc22758a06c46?d=identicon&s=25 FleX (Guest)
on 2013-10-21 18:11
(Received via mailing list)
On 10/21/2013 12:37 AM, Andrea Reginato wrote:
> Evita i test sui controller. Per quel che mi riguarda, duplicano le
> funzionalit
> degli integration test. Una discussiono a riguardo la trovi
> qui<http://betterspecs.org/#integration>
> .

Lettura interessante, ed effettivamente spesso mi chiedo se un
determinato test debba essere inserito nel controller o nel model.

--
FleX
[Linux User #347703 PGP Key ID: 98AA9D3E
FingerPrint: 7D25B 0CE4 898A 22CB F765  E2A5 88B7 4C5C 98AA 9D3E]
114ff87909d3f24150ff3d70d5254338?d=identicon&s=25 Luca Guidi (Guest)
on 2013-10-22 12:09
(Received via mailing list)
Flex, dovresti fare il contrario, prima gli integration, poi gli unit.

L


2013/10/21 FleX <flex@programmareweb.com>
0d4857c0bd9540f743afc22758a06c46?d=identicon&s=25 FleX (Guest)
on 2013-10-22 12:36
(Received via mailing list)
On 10/22/2013 12:08 PM, Luca Guidi wrote:
> Flex, dovresti fare il contrario, prima gli integration, poi gli unit.

perche' ?
Voglio dire prima testo ad esempio che non si possibile creare un record
con un campo unico duplicato e poi verifico con gli integration il
processo di creazione di quel record.


--
FleX
[Linux User #347703 PGP Key ID: 98AA9D3E
FingerPrint: 7D25B 0CE4 898A 22CB F765  E2A5 88B7 4C5C 98AA 9D3E]
51ee8dd7b8bc34df3f121f3be337dad2?d=identicon&s=25 Giuseppe Capizzi (Guest)
on 2013-10-22 12:51
(Received via mailing list)
> perche' ?

Bisognerebbe procedere outside-in [1].

Per quanto riguarda gli integration test, consiglio caldamente la
visione di questa [2] presentazione di Reisenberger. Sinceramente non
capisco perch si considerino i test dei controller uno spreco di
tempo e come si pensa di avere una copertura decente testando
unitariamente solo i model e testando tutto il resto full stack...

[1]
http://coding-is-like-cooking.info/2013/04/outside...
[2] http://www.infoq.com/presentations/integration-tests-scam
5ce16d85034e08079db3cafeb5b8ff09?d=identicon&s=25 Davide Rambaldi (Guest)
on 2013-10-22 13:01
(Received via mailing list)
IMHO: Se testi gli unit prima,  corri il rischio di testare funzionalit
che non servono. Con gli integration invece hai una visione d'insieme
degli stati del programma. Che senso ha testare per la duplicazione di
un record se  un caso che non si presenta mai?

Mah. Io temo I test.

FleX <flex@programmareweb.com> ha scritto:
>
>--
>FleX
>[Linux User #347703 PGP Key ID: 98AA9D3E
>FingerPrint: 7D25B 0CE4 898A 22CB F765  E2A5 88B7 4C5C 98AA 9D3E]
>_______________________________________________
>Ml mailing list
>Ml@lists.ruby-it.org
>http://lists.ruby-it.org/mailman/listinfo/ml

-- Inviato dal mio cellulare Android con K-9 Mail.
Fe88efa62f2b20bdeb8689626d375f1e?d=identicon&s=25 Andrea Campolonghi (andreacfm)
on 2013-10-22 13:03
(Received via mailing list)
Io mi faccio portare dai test.
Comincio dall'integration. Il primo fallimento ovviamente arriva sul
routing che magari non esiste.
Aggiungo il test della rotta e la rotta stessa.
Poi ovviamente il controller non ha la action e auindi aggiungo il test
del controller per la action in questione etc...

Quando l'integration passa ho fatto tutto quello che dovevo testando
tutti i vari aspetti.

just my 2c

Andrea

On Oct 22, 2013, at 12:50 PM, Giuseppe Capizzi <redstarlabs@gmail.com>
wrote:

> [1]
http://coding-is-like-cooking.info/2013/04/outside...
> [2] http://www.infoq.com/presentations/integration-tests-scam
> --
> Giuseppe Capizzi
> _______________________________________________
> Ml mailing list
> Ml@lists.ruby-it.org
> http://lists.ruby-it.org/mailman/listinfo/ml

Andrea Campolonghi
acampolonghi@gmail.com
Dc64befa87f79e074d55f83bcf9daa49?d=identicon&s=25 Silvano Stralla (sistrall)
on 2013-10-22 15:29
(Received via mailing list)
+1 per l'approccio e la spiegazione proposte da Andrea: procedere
outside-in mi permette di rendermi conto, lungo il percorso di
implementazione, se ho le idee chiare su quel che sto facendo. E, nel
caso
non le abbia, di fare il punto della situazione e ripartire.

Per me procedere outside-in significa partire dallo scrivere i test
relativi alla parte di software più "vicina" all'utente (inteso in senso
generico: potrebbe essere una persona fisica o, nel caso di API, una
macchina o, più in generale, qualsiasi entità che interagisce con il
software che sto scrivendo) per scendere negli strati sottostanti (fino
a
fermarmi, idealmente, dove iniziano i test delle librerie su cui baso lo
sviluppo).

Silvano


2013/10/22 Andrea Campolonghi <acampolonghi@gmail.com>

> just my 2c
> > Per quanto riguarda gli integration test, consiglio caldamente la
> > _______________________________________________
> 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/
Please log in before posting. Registration is free and takes only a minute.
Existing account

NEW: Do you have a Google/GoogleMail, Yahoo or Facebook account? No registration required!
Log in with Google account | Log in with Yahoo account | Log in with Facebook account
No account? Register here.