Rails Testing with Factory Girl
hiringthing.com
Rails Testing with Factory Girl
1–10 of 36 posts
Re: Rails Testing with Factory Girl
#2I'm coming to the later stages of implementing an MVP with Rails and for me, FactoryGirl and RSpec have been a godsend.
Re: Rails Testing with Factory Girl
#3Yea, 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).
Re: Rails Testing with Factory Girl
#4Old news!
Re: Rails Testing with Factory Girl
#5I 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.
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.
Re: Rails Testing with Factory Girl
#6Yea, 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).
How is this different to mocking frameworks like RhinoMocks or the new Microsoft.Fakes?
Re: Rails Testing with Factory Girl
#7Factory Girl is good but Fabrication is far better.
Re: Rails Testing with Factory Girl
#8I 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. 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.
If I could upvote the parent any harder, it would hit orbit.
If you need a complex network of collaborators to test a method, the answer is not to obscure the creation of those collaborators, it's to refactor so that each object talks only to its immediate neighbours, and then stub the heck out of them. If it absolutely has to be something that acts like an ActiveModel, then use mock_model().
Re: Rails Testing with Factory Girl
#9I 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. 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.
You can use the build method to instantiate the model without saving to the database. Very useful because you only need use create when you need persistence in your test - such as when testing a controller.
Re: Rails Testing with Factory Girl
#10I 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. 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.
You can use the build method to instantiate the model without saving to the database. Very useful because you only need use create when you need persistence in your test - such as when testing a controller.
Remember to ensure that your build strategy is set on all associations if you want this to work, e.g.
FactoryGirl.define do
factory :user do
association :account, :strategy => :build
end
end
Even if you do this, though, you're still spinning up a whole network of real objects in what is supposed to be a unit test.