Pivotal Labs

Main menu

Skip to primary content
Skip to secondary content
  • About
  • Case Studies
  • Team
    • Executives
    • Locations
      • San Francisco (HQ)
      • Boston
      • Boulder
      • Denver
      • London
      • Los Angeles
      • New York
  • Community
    • Blogs
    • Tech Talks
    • Events
  • Careers
    • Lifestyle
    • Principles & Practices
    • Benefits
    • FAQ
    • Apply
  • Contact
    • Press Room
    • Press Releases
    • In The News
    • Press Kit
  • All
  • Labs
  • Standup
  • Tracker

Start small and compose: A strategy for using FactoryGirl

John Barker
Tuesday, March 5, 2013

While I’m still not entirely sold on FactoryGirl, I often see it being used in a particularly lazy way. Imagine your basic factory:

factory :project

Before long you’re adding relations to projects, and the first thing people do is this:

factory :project do
  association :user
end

This immediately means that every single time you instantiate a project, you’re getting a user as well. In most cases this is more than you want, and if you continue to follow down this path you end up with a huge slow test suite. I prefer a slightly different strategy: start small and compose.

factory :project do
  ...
end

trait :with_manager do
  association :user, factory: :manager
end

This defines a very simple factory :project which gives you only a project and allows you to build a project with an associated user like so:

FactoryGirl.create(:project, :with_manager)

The result is a couple more arguments when you use the factory, but the overall code is more intention revealing.

If this is too much, you could always create a more descriptive factory:

factory :managed_project, parent: :project, traits: [:with_manager]

If you stick with this strategy, you’ll find that tests are more concise, factories are more useful and your test suite run time won’t grow as fast.

  • 0 Shares
  • Share on Facebook
  • Share on Twitter

One comment

  1. Aaron says:

    Nice and succinct article. I think factories are another hammer and nail thing and they’re definitely a great solution to some problems and a terrible solution to others.

    I definitely in favour of this method of extending factories with what you require, it just makes your tests more readable.

    Some of our guys like to have factories that do a lot of work for you. Personally I’m in favour of explicit tests where you do all the work so it’s visible documentation of behaviour, rather than hidden documentation in your factories.

    Cheers

    March 8, 2013 at 2:57 am

Add New Comment Cancel reply

Your email address will not be published.

John Barker

John Barker
New York

Recent Posts

  • Ahead of the curve
  • Letter to myself as a junior developer
  • All evidence points to OOP being bullshit
Subscribe to John's Feed

Author Topics

advice (1)
blame (1)
code (1)
principle (1)
factories (1)
factory_girl (1)
ny (4)
nyc (3)
ruby (2)
testing (1)
composition (1)
fp (2)
functional (2)
future (2)
inheritance (1)
mutability (1)
performance (2)
programming (2)
rant (1)
clojure (1)
lisp (1)
scala (1)
devise (1)
facebook (1)
google+ (1)
oauth (1)
git (1)
bundler (1)
  • About
  • Case Studies
  • Team
  • Community
  • Careers
  • Contact
  • Labs
  • Events

Contact Us

contact@pivotallabs.com
+1 415-77-PIVOT
TwitterLinkedInFacebook

Pivotal Tracker

Tracker is the award-winning agile project management tool that enables real-time collaboration around a shared, prioritized backlog.
Visit pivotaltracker.com >