Close and Go BackBack to Viget

Scratching An Itch: The Rails Model Generator With Factory Girl Support

Mark Cornick
Mark Cornick, Web Developer, December 08, 2008 2

Many development projects start as scratches for a developer’s itch. We do something enough times to decide that not only must there be a better way, but that we’re going to find it.

At Viget, we’ve mostly sworn off fixtures for our test suites. Instead, several of our recent projects have used Thoughtbot’s Factory Girl as a fixture replacement, for which it works very well. However, the Rails generators are not aware of its presence—they still generate fixtures, which we don’t use, and end up deleting. As Clinton has said, you should be automating anything you do repeatedly, and the Rails generators help meet that goal. So, it would be nice if the Rails model generator would stop creating these unused fixtures, and maybe create factories instead.

A new version of Factory Girl dropped at the end of November. Near the top of its change log is this encouraging snippet:

Factory definitions are now detected in subdirectories, such as
  factories/person_factory.rb (thanks to Josh Nichols)

It might not seem like much, but when I read this, a thought entered my mind. Instead of creating one fixture file per model in the generator, what about creating one factory file? After discussing it with other Viget developers on Campfire, the itch was ready to be scratched—we were going to have a model generator that creates factories instead of fixtures.

Less than a day later, the first version was done. It’s literally the same model generator that ships with Rails 2.2.2, but with all the fixture references changed to factories. Not a monumental display of skill, perhaps, and the point about how open source makes all this possible is obvious and oft-repeated. But, still, an itch scratched, and one less thing that’s not fully automated. 

Do you have some itch that bugs you in development? Think about taking an hour or two and scratching it with some code. If it saves you effort and makes your development process easier, it’ll be time well spent.

Mike Breen said on 12/08 at 12:50 PM

Nice post Mark.

I recently had the same itch, http://github.com/hardbap/coulda, except I’m a little more opinionated. I create indexes on foreign keys in the migration and add any associations to the factory. I’m also using shoulda so I create a few tests.

Mark Cornick said on 12/08 at 12:55 PM

Hey Mike, that looks great. Doing the indexes is a good idea - it’s easy to forget until you really notice their absence. And automatically creating the associations is also a good move. Thanks for another addition to the big Rails toolbox.

Commenting is not available in this weblog entry.

We're the Developers

at Viget Labs. We write about web development trends, tips, best practices, industry events, and our projects — all with an emphasis on Ruby on Rails.

Recent Comments

For translating strings you can use Rails I18n backend instead of using inflectors.

The `typus_human_name` is a patch to fix a problem in `human_name` [1].

[1] https://rails.lighthouseapp.com/projects/8994/tickets/2120-humanize-and-human_name-dont-separate-words

Contact Us

Have any questions, comments, ideas, or secrets to share? Let us know.


Sorry, you need to have Javascript enabled to use this form. (Don't blame us, blame the spammers!) If you'd like to contact us, please visit our Contact page.