FactoryGirl build strategy with nested associations

Is it possible to preserve the build strategy when I have a factory for a model that has an association to a second model, which itself has an association to a third model?

In the example below, a Post is associated with a User, and a User is associated with a City. Even when :strategy => :build is used for all associations, post.user and post.user.city end up getting saved to the database. In the interests of a speedy test suite, can I prevent these database writes from happening?

Factory.define do 
  factory :user do
    name "A User"
    association :city, :strategy => :build
  end

  factory :city do
    name "A City"
  end

  factory :post do
    title "A Post"
    body  "Some text here"
    association :user, :strategy => :build
  end
end

post = FactoryGirl.build(:post)

post.new_record?           # True
post.user.new_record?      # False
post.user.city.new_record? # False

Have you tried the alternative block syntax?

Factory.define do 
  factory :user do
    name "A User"
    city { |city| city.association :city, :strategy => :build }
  end

  factory :city do
    name "A City"
  end
end

It's possible to specify different strategies for creating the association: association :author, factory: :user, strategy: :build Keep in mind that this won't save an associated object in the database. Generating the data for has_many association. Generating the data for a has_many association is a bit more complicated. You can define new

It looks like FactoryBot (formerly FactoryGirl) added use_parent_strategy as a configuration option in v4.8.0. It is turned off by default, to turn it on add the following to your spec/rails_helper:

FactoryGirl.use_parent_strategy = true

Relevant pull request on the factory_bot repo: https://github.com/thoughtbot/factory_bot/pull/961

For FactoryGirl + plain Ruby object bliss: Use FactoryGirl.build instead of FactoryGirl.create. Use initialize_with to customize initialization. Outer factories can use attributes_for to build nested resources. For factory linting either: Add #skip_create to each factory definition. Mimic the built-in linting by calling FactoryGirl.build on

As @messanjah said, however for older versions (< v4.8.0) you can do the following:

association :user, :strategy => @build_strategy.class

build_stubbed is the younger, more hip sibling to build; it instantiates and assigns attributes just like build, but that’s where the similarities end. It makes objects look like they’ve been persisted, creates associations with the build_stubbed strategy (whereas build still uses create ), and stubs out a handful of methods that interact

FactoryBot.build_stubbed(:profile) does not call database at all. It creates and assigns attributes to an object to make it behave like an instantiated object. It provides a fake id and created_at. Associations, if any, will be created via build_stubbed too. It will not trigger any validations. Example test performance with build_stubbed is:

factory_bot . factory_bot is a fixtures replacement with a straightforward definition syntax, support for multiple build strategies (saved instances, unsaved instances, attribute hashes, and stubbed objects), and support for multiple factories for the same class (user, admin_user, and so on), including factory inheritance.

In most of my FactoryGirl factories, I was using ‘ association :area ‘, ‘ association :store ‘, and so on. Didn’t think much about these until yesterday. Turns out that FactoryGirl will build/create and save those associated factories, even if you are using FactoryGirl.build or FactoryGirl.build_stubbed. Learned something new there.