Dovremmo usare Faker in Rails Factories?

Question

Mi piace Faker, lo uso sempre nel mio seeds.rb per popolare il mio ambiente di sviluppo con dati dall'aspetto realistico.

Ho anche appena iniziato a utilizzare Factory Girl che consente anche di risparmiare un sacco di tempo, ma quando mi aggiro per il web per gli esempi di codice non vedo molte prove di persone che combinano i due.

D. C'è una buona ragione per cui le persone non usano il falso in una fabbrica?

La mia sensazione è che così facendo aumenterei la robustezza dei miei test seminando dati casuali - ma prevedibili ogni volta, il che, si spera, aumenterebbe le possibilità che un bug spuntasse.

Ma forse non è corretto e non vi è alcun vantaggio rispetto alla codifica di una fabbrica o non vedo una potenziale trappola. C'è una buona ragione per cui queste due gemme dovrebbero o non dovrebbero essere combinate?

Answer 1

Alcune persone sostengono contro di essa, come here.

NON utilizzare l'attributo casuale a valori

Uno schema comune è quello di utilizzare una libreria di dati falsi (come Faker o Forgery) per generare valori casuali sul al volo. Questo può sembrare allettante per nomi, indirizzi e-mail o numeri di telefono , ma non ha uno scopo reale. Creazione di unico valori è abbastanza semplice con le sequenze:

FactoryGirl.define do 
    sequence(:title) { |n| "Example title #{n}" } 

    factory :post do 
    title 
    end 
end 

FactoryGirl.create(:post).title # => 'Example title 1' 

I suoi dati randomizzati potrebbero a un certo punto di trigger risultati imprevisti in alcuni test, rendendo le vostre fabbriche frustrante con cui lavorare.Qualsiasi valore che potrebbero influenzare il vostro risultato di prova in qualche modo dovrebbe essere ignorato, significato:

Nel corso del tempo, si scopre nuovi attributi che causano il test per non riuscire a volte. Si tratta di un processo frustrante, poiché i test potrebbero non riuscire una sola volta su ogni dieci o centinaia di esecuzioni, a seconda di quanti attributi e valori possibili di e la combinazione attiva il bug. Dovrai elencare ogni attributo casuale di questo tipo in ogni test per sovrascriverlo, il che è sciocco. Quindi, crei fabbriche non casuali , annullando in tal modo qualsiasi beneficio della casualità originale. Si potrebbe argomentare, come fa Henrik Nyh, che i valori casuali aiutano a scoprire i bug . Sebbene possibile, ciò significa ovviamente che hai un problema più grande: : buchi nella tua suite di test. Nella peggiore delle ipotesi, l'errore non viene rilevato; nel migliore dei casi si ottiene un criptico messaggio di errore che scompare alla successiva esecuzione del test, rendendo così difficile il debug di . È vero, un errore criptico è meglio di nessun errore, ma le fabbriche randomizzate rimangono un sostituto inadeguato per i test unitari appropriati, la revisione del codice e TDD per prevenire questi problemi.

Le fabbriche randomizzate non solo non meritano lo sforzo, ma danno anche prova di falsa sicurezza nei test, che è peggio di senza alcun test.

Ma non c'è niente che ti impedisca di farlo se vuoi, fallo e basta.

Oh, e c'è un modo ancora più semplice per allineare una sequenza in FactoryGirl recente, quella citazione è stata scritta per una versione precedente.

Answer 2

Mi piace usare Faker e di solito lo faccio quando lavoro con basi di codice più grandi. Vedo i seguenti vantaggi e svantaggi quando si utilizza Faker con Factory Girl:

possibili svantaggi:

• Un po 'più difficile da riprodurre esattamente lo stesso scenario di test (almeno RSpec funziona in tutto questo è necessario richiamare il generatore di numeri casuali di semi di ogni tempo e permette di riprodurre lo stesso test esatto con esso)
• rifiuti generazione di dati di un po 'di prestazioni

possibili vantaggi:

• Rende i dati visualizzati di solito più umanamente comprensibili. Quando si creano i dati dei test manualmente, le persone tendono a tutti i tipi di scorciatoie per evitare la noia.
• Costruire fabbriche con Faker per i test allo stesso tempo fornisce i mezzi per generare buoni dati dimostrativi per le presentazioni.
• Si potrebbe in modo casuale scoperta di casi di bug bordo durante l'esecuzione dei test molto

Answer 3

Spetta a voi.

Secondo me è una buona idea avere dati casuali nei test e mi ha sempre aiutato a scoprire bug e casi d'angolo a cui non pensavo.

Non mi pento mai di avere dati casuali. Tutti i punti descritti da @jrochkind sarebbe corretto (e si dovrebbe leggere l'altra risposta prima di leggere questo), ma è anche vero che si può (e dovrebbe) scrivere che nella vostra spec_helper.rb

config.before(:all) { Faker::Config.random = Random.new(config.seed) } 

questo farà in modo che hai anche test ripetibili con dati ripetibili. Se non lo fai, hai tutti i problemi descritti nell'altra risposta.