May 082008

Dan Manges has a nice write-up on why the factory pattern is better than Rails fixtures: Rails: Fixin’ Fixtures with Factory. The factory is used to create valid objects for testing with default values for all of the fields. These objects can be used in tests without cluttering the test with attributes we do not care about.

On my current project, we like the factory pattern but favor a slightly better syntax. We wanted to replace:



We use the build method (for lack of a better name) to create test data. We are calling a class method on Paperboy in order to create an instance, which seems more consistent with object creation in ruby than calling a method on a Factory class:

In addition to build! (which is like create!), we added a build method which creates the object without saving it. We put our code in a file called factory.rb (which we require in spec_helper.rb) that looks like:

module Factory
  def self.included(base)
  def build(params = {})
    raise "There are no default params for #{}" unless self.respond_to?(
  def build!(params = {})
    obj = build(params)!
  def customer
      :first_name => "Joe",
      :last_name  => "Guy",
      :paperboy   =>,
  def newspaper
      :customer =>,
      :headline => "Read all about it!",
      :paperboy =>,
  def paperboy
      :first_name     => "Paper",
      :last_name      => "Boy",
      :delivery_route => "Main St Route"
ActiveRecord::Base.class_eval do
  include Factory

The build method uses the class name to find the default params, which are defined as a method per class. Then, it merges any user supplied params and creates the object. Now, when we see test code that looks like: :first_name => "some", :last_name => "person"

we can replace it with:

or, if one of the fields is important for the test: :first_name => "joe"

It is easy to swap the word “new” or “create” for “build” or “build!” and then delete the params that we do not care about.

  5 Responses to “Factory pattern with syntactic sugar”

  1. Hi Paul,

    Where do you “require” the file from? Would you put the file in the “lib” directory and then “require” it from app/controllers/application_controller.rb?

    Or should it be “required” only when in the test environment? In which case which approach would you recommend to require this?


  2. Hi Paul,

    It feels like to me, this is a combination between the builder and the factory pattern, something that I’ve been favouring more so on my projects. It looks a lot more elegant in Ruby of course!


  3. Hey Pat,

    We actually started with something that was more like builder, but the complexity was getting in the way, so we simplified to the solution above.

  4. Thanks for this, it is a good way to handle default values. I found one problem, in that if you have a class called (say) ‘Name’ you can get a conflict in your name spaces and some weird errors come up when you inadvertently overwrite various methods in ActiveRecord::Base because of the class_eval include at the bottom of the factory.rb file.

    Fixing it was simple, just prefix the def paperboy, customer etc methods with some arbitrary thing like’_factory_’ and then change the build method like this:

    unless self.respond_to?(“_factory_#{}”)



    Don’t know how all that will come out in Textile, but we’ll see :)

    This way you don’t get any class method clashes.


  5. Hi Greg, we put this file into the test (or spec) folder and then require it from test_helper (or spec_helper). This makes it available for tests and nothing else.

Sorry, the comment form is closed at this time.