Open Source ProjectsCode that Might be Useful to You

Talks I've GivenOn Technologies and Ideas

ThoughtsWhere I Sometimes Write Things

Resume If You Believe In Those

Follow Me On

GitHubIf coding is your thing

TwitterIf you tweet

Boston.rb Hackfest 5/07 Post Mortem

By now, I think it’s a running joke that we’d work on the recommendable plugin we started a month or so ago.

Instead, we worked on the Factory stuff. This article captures most of the ideas of using factories for testing and reasons for using them instead of fixtures.

The crew tonight:


As the article mentions, someone did implement a plugin which captures most of these ideas.

There were a few reasons (and some more which I don’t remember) why we didn’t like this plugin.

  • Plugin, not a gem, so unusable outside of rails
  • Pollutes the namespace of Object
  • No tests

So, the journey for better Factories begins. The basic ideas/goals we settled on is this:

  • Define your factories in test/test_helper.rb
  • Be able to define a factory for a class with default options
  • Be able to define alternate factories for a class, for example, to create an admin user versus a normal user
  • Flexibility for defining default attributes, ie be able to call other methods
  • Choice of making new instance, persisting a new instance, stubbing an instance, or getting valid attributes
  • Flexible API for actually calling the factories


So we started out with a basic API that Dan Croak had outlined:

Factory.define do |factory|
  factory.add :project do |project| {"factoryfu"}
    project.homepage_url {""}
  factory.add :event, :meeting do |event|
    event.event_type {"Meeting"} {}
    event.description {"an sick meeting"}
  factory.add :event, :hackfest do |event|
    event.event_type {"Hackfest"} {}
    event.description {"a cool hackfest"}

As for usage of the factories, we had 3 possibilities:

Factory.create :project, :name => 'ambitious_sphinx'
Factory.create_project :name => 'ambitious_sphinx'
create_project :name => 'ambitious_sphinx'

I’m not going to say much about these, aside from the first being the simplest to implement, the second being the most explicit about what you are doing, and the last is the most concise.

Because it seemed like the simplest, we started implementing the first. I believe that the other two syntaxes can actually be emulated using it.

To simulate the second, as we register factories, we can create the appropriate methods, ie create_event, new_event, valid_event_attributes.

To simulate the third, we can build on the second, and probably do some magic to delegate from TestCase to our Factory.

Implementing it

For simplicity’s sake, we started with our work from last week’s hackfest on

We added the snippet for defining factories into our test_helper.rb, made a new model unit test which used the factory methods, and started a Factory class.

We basically ran the test, watched it blow up horribly, and added some code, until eventually the test passed.

You can see the work we ended up in the hackfest repository under ‘boston_rb’

Of particular interest are:

So, I’m just go over a few of the more interesting bits of the implementation:


This is the entrance into defining our factories.

The implementation isn’t very interesting. We just call the block on Factory. We were originally making new instances of Factory, and passing that to the block, but we then realized that this made it a little trickier to have factory methods be class-level methods.


This is what you use to define how you the factory behaves.

It takes a block which defines how to create new attributes. If you look at the snippet:

event.event_type {"Hackfest"} {}

Notice that event.event_type and are actually taking blocks. This allows us to do, and have this not actually be invoked until object creation.

Factory.add actually passes your block a magical Hash which captures this attribute/attribute creation data. We’ll talk about this has in a little bit.

After we get back from the block, we store in @@model_templates, keyed by the model and kind of the factory.

The Factory methods

We provide three factory methods:

  • valid_attributes: a Hash of valid attributes for the object
  • new: a new unpersisted instance, using valid_attributes
  • create: a persisted instance, using new

You invoke them like:

Factory.valid_attributes :project :project, :name => 'factoryfu', :homepage_url => ''
Factory.create :event, :hackfest, :date => 3.days.ago, :description => 'your looking at it'

The way we parse the arguments is a little tricky. Initially, we only supported the first 2 lines. This meant our method signature looked like:

def, attributes = {})

When we went to support the 3rd line, we thought to go like:

def, kind = 'default', attributes = {})

By doing so, you break the 2nd line, because kind would get set to our attributes.

activesupport provides a solution: Array#extract_options. Basically, it looks at the Array, and pops the last element off the end if it’s a Hash. We use it like:

def self.valid_attributes(model, *args)
  kind, attributes = parse_args(*args)
  # ...


def self.parse_args(*args)
  attributes = args.extract_options!
  kind = args.first || 'default'
  [kind, attributes]


We made a subclass of Hash which lets you define keys like: {}
event.description {"This is going to be SICK!"}

Such that it’s equivalent to:

event[:date] = {}
event[:description] = {"This is going to be SICK!"}

Here’s the implementation:

class BlockfulHash < Hash
  def method_missing(method, *args)    
    # When is given no arguments,
    # it returns a Proc for the block passed to the current method
    # yeah, it's officially a hackfest.
    self[method.to_sym] =

This BlockfulHash is what gets passed to the block given to Factory.add.

What’s next

So, we have something workable here:

  • Uses the syntax we laid out for defining factory
  • Supports the first syntax for using factories (Factory.create :event)

As far as what is left to do:

  • Extract it out of the boston_rb code base
  • More tests
  • Gemify
  • Support Factory.create_event syntax
  • PROFIT!!!


Some links and other ideas tossed around over the course of the night:

comments powered by Disqus