Skip to content


Subversion checkout URL

You can clone with
Download ZIP


attributes_for should honor associations defined in the factory #359

nbt opened this Issue · 23 comments

I've looked over the issues surrounding attributes_for (#316, #274, #261) and I think there's still a problem.

As currently documented in Getting Started, attributes_for

Returns a hash of attributes that can be used to build a[n ...] instance

But as currently implemented, attributes_for elides any associations. For example, if a factory is defined as:

factory :membership do

... attributes_for returns an empty hash:

>> FactoryGirl.attributes_for(:membership)
=> {}

This is surprising. @joshuaclayton says that this is to keep attributes_for ORM agnostic. The suggested workaround is to use build and attributes:

=> {"id"=>nil, "user_id"=>3, "club_id"=>6, "created_at"=>nil, "updated_at"=>nil}

but this isn't useful for testing.

I'd like to propose that the contract of attributes_for is to return a hash of exactly the fields defined in the factory, i.e.:

>> FactoryGirl.attributes_for(:membership)
=> {:user_id => 1002, :club_id => 1004}

(I naively imagine that you can avoid hitting the DB by calling build_stubbed on the associated objects, but I suspect it's more complicated than that.)


The attributes_for strategy isn't going to change to build associations: that's one of the benefits of attributes_for! It never touches any models, ever. This allows it to be blazing fast.

Regarding returning a hash of exactly the fields defined in the factory, that'd be fine - just make sure you declare your factory as:

factory :membership do
  user_id 1002
  club_id 1004

Deriving associations and setting _id attributes is not something that'd be intuitive; something we've discussed is some sort of way to define foreign keys.

Earlier today, I released FG 3.2.0, which allows registering custom strategies. I'd recommend looking into changing the attributes_for strategy to a different class that you've changed the behavior for.

class CustomAttributesForStrategy
  def initialize
    @strategy = FactoryGirl::Strategy::AttributesFor

  delegate :result, to: :@strategy

  def association(runner) # or whatever other strategy name you'd like

FactoryGirl.register_strategy(:attributes_for, CustomAttributesForStrategy)

I was trying to find a way to properly construct params with nested_attributes for my controller specs. Since attributes_for wouldn't give me params entries for _attributes, I've put together a helper method:

  def params_for(factory_name)
    exclude_params = [ "id", "created_at", "updated_at" ]
    f =

    params = f.attributes.except(*exclude_params).dup { |k,v|
      v.macro == :has_many && !v.instance_of?(ActiveRecord::Reflection::ThroughReflection)
    }.each_key do |k|
      assoc_collection = f.send(k)

      unless assoc_collection.empty?
        params["#{k.to_s}_attributes"] = {}

        assoc_collection.each_with_index do |assoc_obj,idx|
          params["#{k.to_s}_attributes"][idx.to_s] = assoc_obj.attributes.except(*exclude_params << "#{}_id")


It's aimed to help only in one specific case (one-to-many associations), but it worked for me so far...


Having some easily documented way to implement this very common use case (I personally think it should be implemented as mentioned in the original issue) would be nice.




+1 Any meaningful app is going to have nested attributes and likely deeply nested as well...


I've been keeping ActiveRecord-specific code out of FactoryGirl since it can be used with all sorts of ORMs/ODMs. Is it possible that this nested attributes solution can work for ActiveRecord, Mongoid, MongoMapper, and Sequel (for each of the largest tiny releases per minor release which supports Rails 3)? If not, I think allowing developers to craft their own solutions is still best. That said, with custom build strategies as I mentioned above, it should be a bit easier.


This would definitely help me out a lot. My tests are rife with factories that build nested models and I've no clean way to test the create/update actions on my controllers without merging the attributes_for hashes manually. Passing in FactoryGirl.attributes_for() works brilliantly when the model being made is flat, but it'd save a lot of time if it would build a hash for models that use accepts_nested_attributes_for.


Funny, I just wrote this:

FactoryGirl.attributes_for(:item_variant).merge({:item_family_id =>})

seconds before receiving the email update! :o) I wish I could just:

Factory.attributes_for(:item_variant, :create_associations => true)

or something.


I think in your specific case you could have just wrote

FactoryGirl.attributes_for(:item_variant, :item_family_id =>

since that's just a flat hash.

In order to get a hash similar to this:

{"name"=>"Test Poll",
    "question"=>"What's one?",

Which I've configured to automatically make everything if I simply do FactoryGirl.create(:poll)

In my controller spec I currently have to do:

poll = FactoryGirl.attributes_for(:poll, :name => "Test Poll", :question => "What's one?")
choice1 = FactoryGirl.attributes_for(:poll_choice, :choice => 1)
choice2 = FactoryGirl.attributes_for(:poll_choice, :choice => 2)
taskable = {:taskable => poll.merge({:choice_attributes => {'1' => choice1, '2' => choice2}})}

Oh yes, good call. I tried but with :item_family => instead of the id.


I've been facing this problem for the last two days and my two cents is this: First, I agree with @joshuaclayton that this probably shouldn't be a build in feature. Between different types of relationships, protected attributes, accessors, etc., there's not a great way to write a master function that can handle all cases. And if you try (which I have), you need to pass so many parameters to handle each edge case that simply calling the function feels ugly.

I came across this post :, and it's worked wonders - for each model, I also define a factory with the Hash class, and building that Factory gives me the attributes that I need with no hassle.


@brycesenz that reminds me of an article I posted on the Giant Robots blog - similar ideas with different uses. Thanks for posting this!


Maybe this will help some folks who are ending up here by googling this issue (like me). I heeded @joshuaclayton's advice and implemented my own solution, specific to Rspec and ActiveRecord 4.0.0.

module ControllerMacros
  def attributes_with_foreign_keys(*args)*args).attributes.delete_if do |k, v| 
      ["id", "type", "created_at", "updated_at"].member?(k)

RSpec.configure do |config|
  config.include ControllerMacros, :type => :controller

Then all I have to do is invoke attributes_with_foreign_keys in my specs and voila. DRY!


@BigNerdRanchDan :thumbsup:, love it!


@BigNerdRanchDan :ok_hand:, thanks!

Note: You forgot to close the do |k,v|.


@BigNerdRanchDan just used it thanks!


If anybody interested I've upgraded @BigNerdRanchDan solution a little bit to support nested attributes:


I stumbled upon this issue when I tried providing the associated record in the attributes_for call.
E.g. attributes_for(:post, blog: blog).
This fails silently. I understand the concerns as to why this does not work, but can we make this raise an exception or at least produce a warning? It's not exactly straightforward to figure out why this is not working, you simply get a hash back without the property you passed in. I think the solution is either to raise an exception or return everything that was passed in. Simply removing stuff that I passed in is really counter-intuitive.
Returning whatever you put in there should work fine too, since most ORMs will complain if you try to pass them attributes that don't exist. The point is to get an error somewhere.


As follow-up to ghost (thank you by the way!), here's a couple tips to help you use this new method:

  1. Put the module ControllerMacros code in a new (or existing) file at ./spec/support/controller_macros.rb.

  2. Don't call FactoryGirl.attributes_with_foreign_keys, just call attributes_with_foreign_keys directly.

Hope that helps.


Thank you, it works perfectly. Also, don't forget to require the module in rails_helper.rb (require 'support/controller_macros')


One thing I found with @ghosts (thank you btw) approach is that*args).attributes will convert ActiveRecord enums into integers in the outputted attributes hash.


If using this for POST params in testing, it will break with something similar to:

     Failure/Error: post :create, comment: attributes_with_foreign_keys(:comment)
       '1' is not a valid content_type

(given an enum called content_type on the comment model)

This enum conversion difference between the two functions was brought up by @dankohn in FactoryGirl.attributes converting enum to integer - Issue #680

In my company model: enum auth_type: { default: 1, ny: 2 }
In my company factory: auth_type "ny"
In rails console:

[1] pry(main)> FactoryGirl.attributes_for(:company)[:auth_type]
[2] pry(main)>['auth_type']

I've added the following to @ghost's code to set the enum attributes back ("content_type"=>"publication"), allowing params to continue to work:

inst.class.defined_enums.each { |k, v| attrs[k] = inst.send(k) }

See below...

def attributes_with_foreign_keys(*args)
  inst =*args)
  attrs = inst.attributes
  attrs.delete_if do |k, v| 
    ["id", "type", "created_at", "updated_at"].member?(k)
  inst.class.defined_enums.each { |k, v| attrs[k] = inst.send(k) }
  return attrs

Hopefully this helps someone who, like me, is using this method and also has enums defined in their model.


Some of you who has come across via google may find this post/code-snippet useful:

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.