On 19 May 2009, at 14:53, Lee L. wrote:
I am trying to specify a controller with RSpec for the first time.
I have been using mock_model to date but, given that the models are
fully implemented, I am wondering if I should be using stub_model.
Based on what I have read, I am struggling to understand the
advantages that stub_model over mock_model might provide.
Should I be using stub_model and if so, why?
Should is a big word here. It depends.
When you use a stub model, you get a real instance of your AR model
object, with the database connection crippled so you can’t
accidentally do something that will make your specs slow. The benefit
of this is that you get all the methods on the model available to the
controller. For example, if you have a User class which takes a
date_of_birth attribute in it’s constructor, you can call the #age
This can make your tests easier to read.
The cost of this is that your controller specs will be covering code
in the model classes as well as the controller you’re explicitly
testing. There is a chance you’ll make a change to the #age method on
your User (maybe you want to specify in days rather than years), make
the user specs pass, and check in believing you’re done. Unwittingly,
you have just broken the controller specs too.
If you read what from the really experienced guys who started this
stuff off say, you’ll hear that mocks are really a design tool. By
creating a mock_model in your controller specs rather than leaning on
the stub_model, you’re designing your ‘ideal model’, rather than being
constrained by whatever default methods activerecord gives you, or you
have already written. I often find that this process drives out much
more elegant interfaces onto the models, and sometimes even shows me
where I need to introduce an intermediate class.
I think this is something you really have to play around with for
yourself to find the right balance for you and your team.