Test your FactoryBot knowledge with a free interactive quiz — 20 questions with answers and explanations. No signup needed to play.
Question 1/12Score 0
How does FactoryBot let a test override a factory's default attribute value?
In this round
How does FactoryBot let a test override a factory's default attribute value?
What is the difference between `FactoryBot.build(:user)` and `FactoryBot.create(:user)`?
What does `FactoryBot.attributes_for(:user)` return, as distinct from `build` or `create`?
Why might a team define multiple related factories with inheritance (e.g. `factory :admin_user, parent: :user do ... end`) rather than one large factory with many conditional branches?
Why is it good practice to name FactoryBot factories after the model they represent (e.g. `factory :user` for the `User` model), unless there's a specific reason not to?
Why might a test prefer `FactoryBot.build(:user)` over `FactoryBot.create(:user)` when persistence isn't actually needed?
Why is it commonly recommended to keep factory-defined default attribute values minimal/valid rather than piling on excessive complexity?
What is an "association" in a FactoryBot factory, such as `association :author, factory: :user`?
What does `FactoryBot.create_list(:user, 5)` do?
What is FactoryBot primarily used for?
How does FactoryBot compare to Rails' built-in fixture files (YAML-based) as a way to generate test data?
What risk does relying on overly elaborate, deeply-nested factory setups introduce for test readability?