Fixtures!

Apro un altro thread, questa volta sulle fixtures.

Ultimamente mi sto trovando a pensare che le fixtures vecchio stile non
erano poi una cosa tanto sbagliata. Sono passato a FactoryGirl tempo fa
e da allora l’ho usato in tutti i progetti, gradendo l’immediatezza con
cui si potevano definire i record per i test direttamente nel test che
stavo scrivendo senza dover passare a definire strutture altrove.

FactoryGirl, o almeno il mio approccio all’uso di FactoryGirl, ha
cominciato a mostrare la corda man mano che la complessit dei progetti
aumentava. Spesso mi trovavo a creare, in testa al test stesso, degli
stonfi di chiamate a FactoryGirl per create tutti gli oggetti necessari,
nei :let di rspec o nei blocchi before. Ovviamente capitava anche il
caso in cui le stesse strutture dovevano essere ripetute in altri test,
quindi moduli, spec helpers e cos via.

La cose poi si complicano quando devi creare degli oggetti collegati tra
di loro, cosa che i before e after hooks di FactoryGirl risolvono molto
bene. Prima del loro avvento per ricordo non pochi problemi.

Ora mi sto chiedendo, ma veramente un vantaggio usare factories inviece
che fixtures: ovvero, davvero cos terribile avere tutti i dati di test
nelle fixtures, con i quali copri la maggioranza (se non tutti) gli
scenari possibili?

Ho trovato questo vecchio post
http://metabates.com/2010/08/15/fixtures-v-factories-cant-we-all-just-get-along/
che mi sembra convincente sul fatto di rispolverare le fixtures e usare
le factories ad integrazione.

Che ne pensate?

-f

Link a un post interessante con cui mi trovo abbastanza d’accordo:

http://ablogaboutcode.com/2012/06/21/fixtures-and-factories/

Complemento con questo post di Steve K.:

http://blog.steveklabnik.com/posts/2012-07-14-why-i-don-t-like-factory_girl

I do use FactoryGirl (or sometimes Fabrication) in my request specs;
once

you’re spinning up the whole stack, factories can be really useful. But
they’re not useful for actual unit tests.

2013/1/28 Fabrizio R. [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