Sollten wir Faker in Rails Fabriken verwenden?

Question

Ich liebe Faker, ich benutze es in meinem seeds.rb die ganze Zeit, um meine dev-Umgebung mit real-aussehenden Daten zu füllen.

Ich habe auch gerade angefangen zu verwenden Factory Girl, die auch eine Menge Zeit spart - aber wenn ich für Code Beispiele im Internet sleuth sehe ich nicht viel Beweise von Menschen die Kombination der beiden.

Frage: Gibt es einen guten Grund, warum Menschen in einer Fabrik keinen Fälscher benutzen?

Mein Gefühl ist, dass ich dadurch die Robustheit meiner Tests erhöhen würde, indem ich jedes Mal zufällige - aber vorhersehbare - Daten säte, die hoffentlich die Wahrscheinlichkeit erhöhen würden, dass ein Fehler auftaucht.

Aber vielleicht ist das falsch und es gibt keinen Vorteil gegenüber der harten Codierung einer Fabrik oder ich sehe keine potenzielle Fallstricke. Gibt es einen guten Grund, warum diese beiden Edelsteine ​​kombiniert werden sollten oder nicht?

Answer 1

Einige Leute dagegen argumentieren, wie here.

NICHT RANDOM -Attribut WERTE

Ein gemeinsames Muster eine gefälschte Datenbibliothek zu verwenden ist (wie Faker oder Forgery) Zufallswerte auf die Fliege zu erzeugen. Dies mag für Namen, E-Mail-Adressen oder Telefonnummern attraktiv erscheinen, aber es dient keinem wirklichen Zweck. Erstellen von einzigartigen Werten ist einfach genug, um mit Sequenzen:

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

    factory :post do 
    title 
    end 
end 

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

Ihre randomisierten Daten an einigen Abzug zu unerwarteten Ergebnissen in Ihren Tests könnten, Ihre Fabriken frustrierend machen, mit zu arbeiten.Jeder Wert, der beeinflussen könnte Ihr Testergebnis in irgendeiner Weise müssten außer Kraft gesetzt werden, Bedeutung:

Im Laufe der Zeit werden Sie neue Attribute entdecken, die Ihren Test verursachen versagen manchmal. Dies ist ein frustrierender Prozess, da Tests nur einmal alle zehn oder hundert Läufe fehlschlagen können - abhängig davon, wie viele Attribute und mögliche Werte vorhanden sind und welche Kombination den Fehler auslöst. Sie müssen jedes beliebige zufällige Attribut in jeden Test auflisten, um es zu überschreiben, was albern ist. Also, Sie erstellen nicht-zufällige Fabriken und negieren damit jeden Vorteil der ursprünglichen Zufälligkeit. Man könnte argumentieren, wie Henrik Nyh, dass zufällige Werte helfen Ihnen Bugs zu entdecken. Wenn möglich, bedeutet das natürlich, dass Sie ein größeres Problem haben: Löcher in Ihrer Testsuite. Im schlimmsten Fall bleibt der Fehler immer noch unentdeckt; Im besten Fall erhalten Sie eine kryptische Fehlermeldung, die verschwindet, wenn Sie das nächste Mal den Test ausführen, macht es schwer zu debuggen. Richtig, ein kryptischer Fehler ist besser als kein Fehler, aber randomisierten Fabriken bleiben ein schlechter Ersatz für ordnungsgemäße Komponententests, Code-Review und TDD, um diese Probleme zu verhindern.

Randomisierte Fabriken sind daher nicht nur nicht die Mühe wert, sie geben Ihnen sogar falsches Vertrauen in Ihre Tests, die schlechter als ohne Tests ist.

Aber es gibt nichts, was dich daran hindert, es zu tun, wenn du willst, mach es einfach.

Oh, und es gibt eine noch einfachere Möglichkeit, eine Sequenz in der letzten FactoryGirl zu inline, das Zitat wurde für eine ältere Version geschrieben.

Answer 2

Ich benutze gerne Faker und normalerweise tun, wenn Sie mit größeren Code-Basen arbeiten. Ich sehe die folgenden Vor- und Nachteile bei der Verwendung von Faker mit Factory Girl:

Mögliche Nachteile:

• Ein bisschen schwieriger, das exakt gleiche Testszenario zu reproduzieren (zumindest RSpec um dies funktioniert durch den Zufallszahlengenerator Anzeige jedes Mal, Samt und ermöglicht es Ihnen, die exakt gleichen Test mit ihm)
• generieren von Daten verschwenden ein wenig Leistung

Mögliche Vorteile zu reproduzieren:

• Macht die Anzeige von Daten in der Regel verständlicher. Bei der manuellen Erstellung von Testdaten neigen die Benutzer zu allen Arten von Abkürzungen, um die Langweiligkeit zu vermeiden.
• Die gleichzeitige Erstellung von Fabriken mit Faker für Tests bietet Ihnen die Möglichkeit, schöne Demo-Daten für Präsentationen zu erstellen.
• Sie könnten zufällig Rand Fall Fehler entdecken, wenn die Tests viel laufen

Answer 3

Es liegt an Ihnen.

Meiner Meinung nach ist es eine sehr gute Idee, zufällige Daten in Tests zu haben, und es hat mir immer geholfen, Bugs und Eckfälle zu entdecken, an die ich nicht gedacht habe.

Ich bereue nie, zufällige Daten zu haben. Alle von @jrochkind beschriebenen Punkte wäre richtig (und Sie sollten die andere Antwort vor dem Lesen dieses man lesen), aber es ist auch wahr, dass Sie kann (und sollte) schreiben, dass in Ihrem spec_helper.rb

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

dies so machen dass Sie wiederholbare Tests mit wiederholbaren Daten haben. Wenn Sie das nicht tun, haben Sie alle Probleme, die in der anderen Antwort beschrieben sind.