How can I get Factory Girl to NEVER hit the database if I am calling Factory.build in order to make my controller tests FAST?

Well, I guess I will answer my own question. I think it's the right answer, and maybe others can learn from it as I had to spend a few hours to learn it.

Well, I guess I will answer my own question. I think it's the right answer, and maybe others can learn from it as I had to spend a few hours to learn it. Here's how I got a 2000% (or 20x) speed improvement: before(:each) do @user = User.

New controller. Stub(:authenticate_user! ) controller.

Stub(:current_user). And_return(@user) controller. Stub(:add_secure_model_data) @site_update = SiteUpdate.

New @comment = Comment. New end The solution is simply not to use Factories of any kind for controller tests (and perhaps other kinds of tests). I suggest only use Factory's when it is too much of a pain in the ass to do otherwise.

All 3 tests now run in 0.07 seconds! Before it was 1.4 seconds to run all 3 tests. Factory_girl is simply a terribly slow library.

I don't know what the heck it is doing, but it is not profiled properly. Yes, I know it's doing a lot more than simple MyClass. New statements... but even for a slower scripting language like Ruby, the performance is many orders of magnitude slower than basic class instantiation.It needs to undergo some massive optimization so that Factory.

Build(:my_class) is brought more in line with MyClass. New I would suggest to the implementers of Factory_girl to try and get it so that it's overhead is not much slower than a basic MyClass. New call (excluding database overhead... that can't be avoided).

It should provide a nice way to build objects and you shouldn't have to pay a 20x performance penalty to get this benefit. That's not an acceptable trade-off. This is all really too bad, because Factory.

Build would be nice in controllers when you have render_views turned on inside of your controller specs. There should be significant motivation to correct this.In the meantime, just use basic Ruby/Rails classes. I think you'll be amazed how fast they actually are....

1 I smell a fork... – diedthreetimes May 25 at 20:42 Comparing a stub to any database writes is hardly a fair comparison. If you compare the time taken by factory girl, vs the time taken by manually written Rails' model. Create calls, the difference is tiny.

The root of your problem was that the build strategy for objects associated with a build factory call is to create them, resulting in DB calls. The solution would have been to not use factories for the associations. – Douglas F Shearer May 25 at 22:05 Docs for factory girl built strategies: rubydoc.Info/gems/factory_girl/1.3.3/file/… – Douglas F Shearer May 25 at 22:06 1 One final thing... Stubs and mocks are the way to go for controllers regardless of performance of factories, makes them a proper unit test.

– Douglas F Shearer May 25 at 22:07 @Douglas F Shearer: I am comparing apples to apples. Comment. New is many orders of magnitude FASTER than Factory.

Build(:comment) - even if it has NO associations. There is something really wrong with factory_Girl when making basic objects.It takes .1 seconds, which is really unacceptable. Ruby is slow... but nowhere near that slow.

Should it really take 1/10th of an entire second to make 1 model object and set some attributes on it? What the heck is it doing? – Fire Emblem May 25 at 22:31.

I cant really gove you an answer,but what I can give you is a way to a solution, that is you have to find the anglde that you relate to or peaks your interest. A good paper is one that people get drawn into because it reaches them ln some way.As for me WW11 to me, I think of the holocaust and the effect it had on the survivors, their families and those who stood by and did nothing until it was too late.