Czy powinniśmy używać Fakera w Rails Factories?

Question

Uwielbiam Faker, używam go w moim seeds.rb cały czas, aby zapełnić moje środowisko dev z prawdziwymi danymi wyglądającymi.

Po prostu zacząłem używać Factory Girl, co również oszczędza mnóstwo czasu - ale kiedy śledzę w Internecie przykłady kodu, nie widzę wielu dowodów na to, że ludzie łączą te dwa.

P. Czy istnieje dobry powód, dla którego ludzie nie używają robotników w fabryce?

Mam wrażenie, że dzięki temu zwiększyłabym wytrzymałość moich testów, przesyłając przypadkowe, ale przewidywalne dane za każdym razem, co, miejmy nadzieję, zwiększyłoby szansę pojawienia się błędu.

Ale może to jest nieprawidłowe i nie ma żadnej korzyści z twardego kodowania fabryki lub nie widzę potencjalnej pułapki. Czy istnieje dobry powód, dlaczego te dwa klejnoty powinny lub nie powinny być łączone?

Answer 1

Niektórzy twierdzą przeciwko niemu, jako here.

NIE UŻYWAJ RANDOM wartości atrybutów

Jeden wspólny wzór jest użycie fałszywego biblioteka danych (jak Faker lub Fałszerstwo) do generowania wartości losowych na locie. Może to wydawać się atrakcyjne dla nazw, adresów e-mail lub numerów telefonów , ale nie służy to żadnemu celowi. Tworzenie unikalnych wartości jest dość prosta z sekwencji:

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

    factory :post do 
    title 
    end 
end 

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

Twoje randomizowane dane może w pewnym momencie wyzwalania nieoczekiwane wyniki w testach dokonywania fabryki frustrujące pracować.Każda wartość, która może mieć wpływ na wynik testową w jakiś sposób musiałaby być przesłonięta, znaczenie:

biegiem czasu, będziemy odkrywać nowe atrybuty, które powodują swój test nie czasami. Jest to frustrujący proces, ponieważ testy mogą się nie powieść tylko raz na dziesięć lub sto przebiegów - w zależności od tego, ile jest atrybutów i możliwych wartości, i która kombinacja uruchamia błąd. Będziesz musiał wymienić każdy taki losowy atrybut w każdym teście, aby go zastąpić, co jest głupie. Tworzysz zatem nie-losowe fabryki , tym samym zanegując jakąkolwiek korzyść z pierwotnej losowości. Można się spierać, jak robi to Henrik Nyh, że wartości losowe pomogą ci odkryć błędy. O ile to możliwe, oznacza to oczywiście, że masz większy problem: dziury w pakiecie testowym. W najgorszym przypadku błąd nadal pozostaje niewykryty; w najlepszym przypadku otrzymujesz tajemniczy komunikat o błędzie , który znika przy następnym uruchomieniu testu, przez co trudno jest debugować. To prawda, że ​​tajemniczy błąd jest lepszy niż brak błędu, ale losowe fabryki pozostają słabym zamiennikiem właściwych testów jednostkowych, przeglądu kodu i TDD, aby zapobiec tym problemom.

Losowe fabryki nie tylko nie są warte wysiłku, ale nawet dają fałszywe zaufanie do testów, które są gorsze niż bez żadnych testów.

Ale nic nie powstrzyma cię przed zrobieniem tego, jeśli chcesz, po prostu to zrób.

Aha, i jest jeszcze łatwiejszy sposób na wstawienie sekwencji w ostatnim FactoryGirl, ten cytat został napisany dla starszej wersji.

Answer 2

Lubię używać Fakera i zwykle robię to podczas pracy z większymi bazami kodów. Widzę następujące zalety i wady stosowania faker z fabryką Dziewczyna:

Możliwe wady:

• Nieco trudniej odtworzyć dokładnie ten sam scenariusz testowy (przynajmniej RSpec działa wokół to poprzez wyświetlanie generator liczb losowych nasion za każdym razem i pozwala odtworzyć dokładnie ten sam test z nim)
• odpadów danych Generowanie nieco wydajności

Możliwe zalety:

• Sprawia, że ​​wyświetlane dane są zwykle bardziej zrozumiałe dla człowieka. Podczas ręcznego tworzenia danych testowych ludzie mają tendencję do wszelkiego rodzaju skrótów, aby uniknąć nudy.
• Budowanie fabryk przy pomocy Fakera do testów zapewnia jednocześnie możliwość generowania ładnych danych demonstracyjnych dla prezentacji.
• Można przypadkowo odkryć krawędzi przypadków błędów podczas uruchamiania testów dużo

Answer 3

To zależy od Ciebie.

Moim zdaniem to bardzo dobry pomysł, aby mieć losowe dane w testach i zawsze pomógł mi odkryć błędy i narożniki, o których nie myślałem.

Nigdy nie żałuję, że dane są losowe. Wszystkie punkty opisane przez @jrochkind byłoby poprawne (i powinieneś czytać drugą odpowiedź przed przeczytaniem tego jednego), ale prawdą jest również, że można (i należy) napisać, że w swojej spec_helper.rb

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

będzie to zrobić tak że masz powtarzalne testy z danymi powtarzalnymi. Jeśli tego nie zrobisz, masz wszystkie problemy opisane w drugiej odpowiedzi.