Come fate il testing?

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]

Evita i test sui controller. Per quel che mi riguarda, duplicano le
funzionalit
degli integration test. Una discussiono a riguardo la trovi
quihttp://betterspecs.org/#integration
.

2013/10/20 FleX [email protected]

applicando il refactoring
FingerPrint: 7D25B 0CE4 898A 22CB F765 E2A5 88B7 4C5C 98AA 9D3E]


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


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

On 10/21/2013 12:37 AM, Andrea R. wrote:

Evita i test sui controller. Per quel che mi riguarda, duplicano le
funzionalit
degli integration test. Una discussiono a riguardo la trovi
quihttp://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]

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

On 10/22/2013 12:08 PM, Luca G. 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]

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-in-development-with-double-loop-tdd/
[2] http://www.infoq.com/presentations/integration-tests-scam

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


FleX
[Linux User #347703 PGP Key ID: 98AA9D3E
FingerPrint: 7D25B 0CE4 898A 22CB F765 E2A5 88B7 4C5C 98AA 9D3E]


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

– Inviato dal mio cellulare Android con K-9 Mail.

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

[1]
http://coding-is-like-cooking.info/2013/04/outside-in-development-with-double-loop-tdd/
[2] http://www.infoq.com/presentations/integration-tests-scam

Giuseppe C.


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

Andrea C.
[email protected]

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

just my 2c

Per quanto riguarda gli integration test, consiglio caldamente la


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/

Flex, dovresti fare il contrario, prima gli integration, poi gli unit.

L

2013/10/21 FleX [email protected]

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs