Rails Testing with Factory Girl

I hate when people are using it in the unit tests. It just makes testing very convenient, so they start using it everywhere. In the end, the test suite gets very slow. Unit tests should not hit the database.<p>First example there: test_new_customer_defaults. Really, it needs 3 saved models to test this? FactoryGirl isn't solution here. It's just hiding the problem.

A response from a naysayer:<p><i>Factories are slow.</i> Yes, they really are. Persisting everything along a chain of associations will <i>always</i> be slower than properly isolating the dependencies of the unit under test, SSD or not. It's easier to enjoy Ruby when not constantly waiting minutes for tests to run.<p><i>Factories increase the over-all complexity of your app.</i> Are you kidding me? Yes, they <i>do</i>. Expertise and huge, easy gains have nothing to do with reducing complexity and more often (but not always) increase it. A test suite where every test depends on state in a database is more complex than one that tests units in isolation.<p>None of these points are arguing against Factory Girl, which is a great tool for doing what it does; they are arguing against integrating with the database in "unit" tests.

As a guy who recently switched from years of ASP.Net MVC to Rails, I read this post and wanted to shout...<p>"Watch out everybody, he's hitting the database!!!"<p>Ruby is a great language that I love, but this is one of those cases where Ruby's conciseness and readability hide a TON of complexity. And complexity in tests is death.<p>I've seen it for myself -- there's a lot of technical debt interest in those tests. It looks manageable at the beginning, especially within the scope of a blog post, but when the app grows and grows and grows, the tests fail.

To get the best form both fixtures and factories, I can strongly recommend <a href="http://github.com/rdy/fixture_builder" rel="nofollow">http://github.com/rdy/fixture_builder</a> It utilizes factories to build up your fixtures. This way you only need to specify what you actually care about in you r fixture which preserves readability. But you still get the speed of fixtures. The one downside is that you can never assume a complete knowledge of what's in your DB. This might break test for scopes for example.<p>However I more and more agree with the general notion that your unit test should not hit the DB. However, Rails works against that. Avdi Grimm's "Object's on Rails" (<a href="http://objectsonrails.com/" rel="nofollow">http://objectsonrails.com/</a>) has some interesting suggestions on how to get some good test isolation out of Rails.

Factory Girl has saved me countless hours - I love it.<p>You can use build instead of create to avoid the db, as per previous comments. You don't have to use it at all if writing a simple unit test.<p>But for teeing up complex scenarios prior to a fat integration test, it rocks.

I'm coming to the later stages of implementing an MVP with Rails and for me, FactoryGirl and RSpec have been a godsend.

Old news!

Yea, once your model gets more complex than a dozen or so objects, then something like this is awesome. I only with there was an equivalent in ASP.Net MVC which is the current bill payer. (Plant is the closest I've seen, but not quite as elegant, and I'm a little concerned over support).

Factory Girl is good but Fabrication is far better.