Forum: RSpec When to stub_model?

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
05748a61a1b05130ec508434301aecf1?d=identicon&s=25 Lee Longmore (Guest)
on 2009-05-19 16:01
(Received via mailing list)
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?

Thanks.
Cdf378de2284d8acf137122e541caa28?d=identicon&s=25 Matt Wynne (mattwynne)
on 2009-05-19 19:18
(Received via mailing list)
On 19 May 2009, at 14:53, Lee Longmore 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
method.

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[1] 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.

Matt Wynne
http://blog.mattwynne.net
http://www.songkick.com
Cdf378de2284d8acf137122e541caa28?d=identicon&s=25 Matt Wynne (mattwynne)
on 2009-05-19 20:59
(Received via mailing list)
On 19 May 2009, at 18:11, Matt Wynne wrote:

>>
> call the #age method.
> If you read what from the really experienced guys who started this
> yourself to find the right balance for you and your team.
>
> Matt Wynne
> http://blog.mattwynne.net
> http://www.songkick.com

[1]http://www.m3p.co.uk/blog/2009/03/08/mock-roles-no...

Matt Wynne
http://blog.mattwynne.net
http://www.songkick.com
753038ae16700c0fd9a5e1d2e80f68f6?d=identicon&s=25 Lee (Guest)
on 2009-05-20 13:12
(Received via mailing list)
Thanks Matt. Very helpful.

I have tried out stub_model. The constructor of one of my models
(Namespace) requires a mandatory :name attribute to be provided. So
when I try to stub_model it - e.g. representative_namespace =
stub_model(Namespace) - I get the following spec error.

1)
RuntimeError in 'ContextsController POST create authenticated user
should assign a representative namespace to the new context'
A namespace must be assigned a valid name
/Users/leelon/work/cbox/app/models/namespace.rb:696:in
`raise_no_name_error'
/Users/leelon/work/cbox/app/models/namespace.rb:688:in
`get_processed_name'
/Users/leelon/work/cbox/app/models/namespace.rb:643:in `set_name'
/Users/leelon/work/cbox/app/models/namespace.rb:64:in `initialize'
./spec/controllers/contexts_controller_spec.rb:37:
script/spec:10:

Is there a way around this while still making :name a mandatory
requirement of the constructor? I have tried stubbing out :name in the
call to stub_model but this doesn't help:

representative_namespace = stub_model(Namespace, :name => 'A name')

Thanks.
Cdf378de2284d8acf137122e541caa28?d=identicon&s=25 Matt Wynne (mattwynne)
on 2009-05-20 15:15
(Received via mailing list)
On 20 May 2009, at 12:03, Lee wrote:

> A namespace must be assigned a valid name
> requirement of the constructor? I have tried stubbing out :name in the
> call to stub_model but this doesn't help:
>
> representative_namespace = stub_model(Namespace, :name => 'A name')

I can't remember if you can do that, to be honest. I think the hash of
parameters to stub_model is used to set up stubs on the object - so
they won't get passed to the constructor. Hopefully someone else on
the list should be able to tell you if this is possible.

Matt Wynne
http://blog.mattwynne.net
http://www.songkick.com
753038ae16700c0fd9a5e1d2e80f68f6?d=identicon&s=25 Lee (Guest)
on 2009-05-20 15:28
(Received via mailing list)
> I can't remember if you can do that, to be honest. I think the hash of
> parameters to stub_model is used to set up stubs on the object - so
> they won't get passed to the constructor. Hopefully someone else on
> the list should be able to tell you if this is possible.

Matt, I have since looked at the source for stub_model on RSpec's RDoc
and I think you're right and it's not possible. I guess one option
would be to fallback to mock_model for this model.
This topic is locked and can not be replied to.