In principle, I agree with you: you get the most benefits of a factory tool by creating the test data as close to the test as possible. And if your primary reason to switch to a factory tool from fixtures is to be abel to see the data creation right next to the test, so that you don’t have to switch to another file to see the contents of a test object…then preloading a bunch of data using my gem (or a similar solution) would be a bad idea.

In my case, my primary reason for hating fixtures and moving to a different tool is because I want all my test data to be created through the models themselves, rather than just being inserted directly into the database. This means my test data has passed validations, and any associated records created by before/after save callbacks will also exist.

The test suite on my current project is at 2500+ tests and counting. I wish it was faster than it is. My factory_data_preloader gem has been a big help in speeding it up, but it’s still slower than I’d like it (about 7-8 minutes total right now, I think).

I use mocks quite a bit too. It’s a technique I find myself using more and more. Maybe we wouldn’t have the speed issues if I had use mocking early on.

@myron Usually a avoid creating unnecessary data, I just call “make” when that record will be used. some auxiliary data, I may also use make_unsaved, and it will not hit the database.

The advantages of a factory tool are best realized if you create the fewest number of objects you need to expose each test, and if you create them as close to the actual test as possible. Creating more objects slows the tests down a lot. Creating the data away from the test has the same problem as fixtures — test values that seem magical because you can’t see the data that caused them.

Mocks are another alternative for speeding up tests… More on that tomorrow.

I tried to address this (with some success) with a gem:

http://github.com/myronmarston/factory_data_preloader/tree/master

It should be compatible with any fixture replacement, though I’ve only personally used it with factory girl.

How have others solved the speed issue?

Commenting from iPhone can be sloppy

A small correction for Machinist. You need to use a block to assign a simple value in a blueprint.

name ‘Test Data’

works fine

Machinist FTW.

A few corrections about FixtureReplacement:

As of FixtureReplacement v 2.1, db/example_data.rb is no longer necessary.

You can also call your factories inline, if you so please:

http://gist.github.com/116456

And define them that way, too:

http://gist.github.com/116457

You could also create your own wrappers around it:

http://gist.github.com/116459

I think you got build and create reversed for factory_girl, by the way: Create saves, build doesn’t, just like ActiveRecord.

I definitely gotta echo the point about creating the minimal data necessary for a good test. One colleague of mine once created a test which ran the same assertion against 1,000 different permutations of the data, basically testing that every input X between 0 and 1,000 would output the expected Y; I gotta hand it to him for being thorough, but not only was it unnecessary, but it made the test run so slowly that I had to comment it out just so I could be productive with autotest.