Mock and Stub objects

tornado · June 10, 2009, 12:55pm

Hello,

  I had seen many controller spec using mock and stub objects.

  I had written controller spec earlier without these objects.

  In the book it is mention about mock and stub objects.but i am

still not getting the reason behind it.

  Can somebody tell me what are these and why are we using it

especially in controllers?

tornado · June 10, 2009, 7:59pm

On Wed, Jun 10, 2009 at 5:55 AM, Amit K.[email protected]
wrote:

Hello,

 I had seen many controller spec using mock and stub objects.

 I had written controller spec earlier without these objects.

 In the book it is mention about mock and stub objects.but i am

still not getting the reason behind it.

Did you read the chapter on Mock Objects?

tornado · June 10, 2009, 8:41pm

On Wed, Jun 10, 2009 at 6:55 AM, Amit K.[email protected]
wrote:

 In the book it is mention about mock and stub objects.but i am
still not getting the reason behind it.

The Very Short Answer: You don’t want your controller specs failing
because your model is broken. Your model specs should fail instead.
You also don’t want your controller specs running slow because it’s
hitting a database. (That, again, is the model’s problem.)

The answer to this is not to talk to the model in your controller
specs. Your specs talk only to the controller. For everything else,
you create one or more fake model-like thingies that give all the
right answers when asked the right questions.

Then, when your controller specs fail, you know where to focus your
energy. In the controller.

(That, or they fail because the specs or the mocks and stubs are
slightly wrong. In my experience that’s more common, and that’s one
reason why I hardly ever do controller specs any more. But still:
there you go. That’s the reason for the way it’s done canonically.)

–
Have Fun,
Steve E. ([email protected])
ESCAPE POD - The Science Fiction Podcast Magazine
http://www.escapepod.org

tornado · June 11, 2009, 9:17am

David C. wrote:

On Wed, Jun 10, 2009 at 5:55 AM, Amit K.[email protected]
wrote:

Hello,

ï¿½ ï¿½ ï¿½I had seen many controller spec using mock and stub objects.

ï¿½ ï¿½ ï¿½I had written controller spec earlier without these objects.

ï¿½ ï¿½ ï¿½In the book it is mention about mock and stub objects.but i am
still not getting the reason behind it.

Did you read the chapter on Mock Objects?

Yes i have read Mock Objects.
I understood a bit that Mock object create objects virtually so that we
can run our specs.It helps us in that we dont have to actually create
those objects.

But i am still not getting my hand on it.

we may have a situation that just for instance that all the development
is done and we are now writing the spec for it.In this case all the
coding in controller,model are done.
So when we write specs for controller do we have to create mock objects?
What if we write specs in controller without using mock objects?Will it
be fine?

Also since i am using the beta version Mocking Objects part is not
there.And it is does not give clearcut idea from the topic Mock Objects.
Also it will be very helpful if you can provide me a link or anything
which can give me details of Mocks and Stubs.How to use it?When to use
it…e.t.c

Thanks & Regards,

Amit

tornado · June 11, 2009, 11:39am

Matt W. wrote:

On 11 Jun 2009, at 08:17, Amit K. wrote:

those objects.
it
be fine?

If you’re writing the specs after you’ve written the code, you’re
losing a lot of the value of mock objects.

Actually i am writing specs before the code is written.I saw many
examples especially in controllers they are using mocks.So i was bit
confused regarding the same.

Also Imagine the same situation where code is written and we are writing
specs for that then is it necessary to use mocks?If Yes why since code
is already written?

Mock objects were originally devised as a design tool for use when
doing TDD. TDD stands for Test Driven Development, meaning that you
write the test before you have written any of the code. When you’re
doing this, you want to be able to build the system piece by piece,
class by class, so you write tests for a single object at a time, and
use mock objects to assemble quick, lightweight sketches of the
surrounding objects that you imagine it will interact with when the
system is finished.

Also since i am using the beta version Mocking Objects part is not
there.And it is does not give clearcut idea from the topic Mock
Objects.
Also it will be very helpful if you can provide me a link or anything
which can give me details of Mocks and Stubs.How to use it?When to use
it…e.t.c

This is a big topic which is not going to be easy to explain over
email. Here is some more stuff for you to read.

http://www.patmaddox.com/blog/you-probably-dont-get-mocks
http://www.mockobjects.com/book/
http://www.jmock.org/oopsla2004.pdf
Mocks Aren't Stubs

Thanks a lot Matt for the above links.

tornado · June 11, 2009, 10:45am

On 11 Jun 2009, at 08:17, Amit K. wrote:

those objects.
it
be fine?

If you’re writing the specs after you’ve written the code, you’re
losing a lot of the value of mock objects.

Mock objects were originally devised as a design tool for use when
doing TDD. TDD stands for Test Driven Development, meaning that you
write the test before you have written any of the code. When you’re
doing this, you want to be able to build the system piece by piece,
class by class, so you write tests for a single object at a time, and
use mock objects to assemble quick, lightweight sketches of the
surrounding objects that you imagine it will interact with when the
system is finished.

Also since i am using the beta version Mocking Objects part is not
there.And it is does not give clearcut idea from the topic Mock
Objects.
Also it will be very helpful if you can provide me a link or anything
which can give me details of Mocks and Stubs.How to use it?When to use
it…e.t.c

This is a big topic which is not going to be easy to explain over
email. Here is some more stuff for you to read.

http://www.patmaddox.com/blog/you-probably-dont-get-mocks
http://www.mockobjects.com/book/
http://www.jmock.org/oopsla2004.pdf

Matt W.

http://blog.mattwynne.net

tornado · June 11, 2009, 3:42pm

On Thu, Jun 11, 2009 at 4:39 AM, Amit K.[email protected]
wrote:

Actually i am writing specs before the code is written.I saw many
examples especially in controllers they are using mocks.So i was bit
confused regarding the same.

Also Imagine the same situation where code is written and we are writing
specs for that then is it necessary to use mocks?If Yes why since code
is already written?

It’s not a matter of necessity, but rather a matter of costs and
benefits. This is a very complex and subtle topic, which is one reason
a lot of people who avoid mocking do so. At some level, it is simpler
to not use any mocks or stubs anywhere. But if you choose that path,
there are a lot of benefits you’re missing out on.

Steve wrote in his reply earlier in this thread that we don’t want out
controller specs failing because the model is broken. But it’s not
just when the model breaks. It’s when the model changes.

Say, for example, that we’ve got a Widget model that has a required
name attribute, and an optional date attribute. We’ve got this in our
controller spec:

describe WidgetsController do
describe “POST create” do
context “with valid attributes” do
it “redirects to the widget list” do
post :create, :widget => {:name => ‘Foo’}
response.should redirect_to(widgets_path)
end
end
context “with invalid attributes” do
it “re-renders the ‘new’ template” do
post :create, :widget => {} #missing the required name
response.should render_template(‘new’)
end
end
end
end

Now imagine that we’re working on the model spec and we get a new
requirement that the date is required. So we write a spec:

describe Widget do
it “requires a date attribute” do
Widget.new(:name => ‘Foo’, :date => nil).should_not be_valid
end
end

That fails, so we add “validates_presence_of :date” to the model and
then the spec passes. Success! Except now the valid attributes case in
the controller spec fails because we’ve changed the meaning of valid
for this model. So you have to go back and change this and every other
example that creates a Widget without a date.

Now stubs/mocks are certainly not the only way to fix this problem.
You can use fixtures, centralized helper methods, object mothers, and
test data builders. These are all tools that help you centralize the
creation of objects, so when you do run into this sort of problem, you
only need to fix it in one place. But you still need to fix it once,
which takes your focus away from the task at hand. And you don’t get
the speed savings you get w/ stubs/mocks. And you still get controller
specs failing when models are broken.

For the record, I generally use stubs/mocks in controller specs, but I
tend towards test data builders in model specs. But I’m also very
comfortable with all of these tools and am perfectly willing to use
test data builders in controller specs or mocks/stubs in model specs
when that is the better choice for a given situation. Really, I think
that’s what we should all be striving for. Not so much “should I use
mocks or not,” but “when should I choose to use them?”

HTH,
David

tornado · June 11, 2009, 6:42pm

(NOTE: This reply is no longer really for Amit’s benefit any more.
What David said made perfect sense as an answer to the original
question. Now I’m just spinning off into theory.)

((But David – if the repetition of this whole argument

On Thu, Jun 11, 2009 at 9:36 AM, David C.[email protected]
wrote:

Steve wrote in his reply earlier in this thread that we don’t want out
controller specs failing because the model is broken. But it’s not
just when the model breaks. It’s when the model changes.

True. Though if I wanted to play Devil’s Advocate, I could make a
case that from the point of view of the controller, it’s the same
thing. “What? The Widget wants WHAT now? Hey, I know all about
widgets, and this widget’s not doing what I expect any more. Must be
something wrong with it.”

(Of course, that exact attitude points to a lot of what’s wrong in
human relationships, not just OO ones. >8-> So I wouldn’t defend
that case rigorously. Still – it’s a problem that can be exacerbated
by the sort of static expectation mocks play into.)

That fails, so we add “validates_presence_of :date” to the model and
then the spec passes. Success! Except now the valid attributes case in
the controller spec fails because we’ve changed the meaning of valid
for this model. So you have to go back and change this and every other
example that creates a Widget without a date.

Yep. But isn’t the difference just a matter of timing? If you just
added a new requirement to Widgets, the controller needs to change
before you hit production or it’s going to break in real-world use.
You’ll eventually have to go back and change every mock, and then
change every example anyway. If you don’t, then the mocks no longer
represent the true expectation of a Widget and your controller’s
behavior is no longer correct from the widget’s POV. You end up with
specs that pass when the application wouldn’t.

As a matter of practicality, I think I would prefer the controller
spec to fail right away so that I don’t forget to update my mocks
later on. Yes, I should have integration tests that would catch
this, so I ought to be safe if I’m doing other things right; but if
the controller spec will have to change sooner or later, I’d rather it
bugged me to change it sooner.

As I see it, the cost of violating DRY and repeating the expectations
of a Widget in a number of mocks, which then have to be maintained
separately, is usually higher than the cost of referring to the
actual model, with slower test runs and less specific failure
pinpointing. I don’t see earlier spec repair as a cost at all, given
that those specs will have to change anyway. There may be cases where
this would pay off to me, but the typical highly coupled Rails
model/controller relationship isn’t it. In practice I only use mocks
these days to take the place of outside interfaces or bigger, more
conceptually distinct subapplications.

[ . . . ] Really, I think
that’s what we should all be striving for. Not so much “should I use
mocks or not,” but “when should I choose to use them?”

And here… Here you made me really pause and think.

Enough to make it a separate message.

–
Have Fun,
Steve E. ([email protected])
ESCAPE POD - The Science Fiction Podcast Magazine
http://www.escapepod.org

tornado · June 11, 2009, 7:14pm

On Thu, Jun 11, 2009 at 11:36 AM, Stephen E.[email protected] wrote:

just when the model breaks. It’s when the model changes.
by the sort of static expectation mocks play into.)
before you hit production or it’s going to break in real-world use.
This may be true in some cases, but generally with validations the
controller passes the params straight through to the model without
caring about them in any way. In those cases, where the controller is
only interacting with methods that are part of AR::Base, you’re not
really risking a validation change effecting the controller’s
behaviour.

You’ll eventually have to go back and change every mock, and then
change every example anyway. If you don’t, then the mocks no longer
represent the true expectation of a Widget and your controller’s
behavior is no longer correct from the widget’s POV. You end up with
specs that pass when the application wouldn’t.

I think you’re generalizing here, which is what I was driving at with
my point about knowing when to use stubs/mocks and when not to. As I
mentioned above, these changes need not always propagate up to the
controller or its specs. I would agree with you that there is
additional risk in cases where the changes to the model actually do
require changes to the controller. Though I mitigate that risk by
working with Cucumber first, which catches those sorts of
mis-alignments a bit later than if I wasn’t using stubs/mocks, but
certainly before those changes make it to production.

At the moment, one of my projects does not use Cucumber. We’re using
RSpec for both higher level and lower level specs. In this case, the
level of use of stubs/mocks is far lower than in other projects I’ve
worked on.

As a matter of practicality, I think I would prefer the controller
spec to fail right away so that I don’t forget to update my mocks
later on. Yes, I should have integration tests that would catch
this, so I ought to be safe if I’m doing other things right; but if
the controller spec will have to change sooner or later, I’d rather it
bugged me to change it sooner.

I can appreciate that, though it’s not how I operate.

As I see it, the cost of violating DRY and repeating the expectations
of a Widget in a number of mocks, which then have to be maintained
separately, is usually higher than the cost of referring to the
actual model, with slower test runs and less specific failure
pinpointing.

I run the specs after every change (using autospec). For this to work
effectively, the specs need to run fast. This is one of the benefits,
in my view, of having two separate tools for dealing at different
views of the code (i.e. RSpec and Cucumber).

mocks or not," but “when should I choose to use them?”

And here… Here you made me really pause and think.

Enough to make it a separate message.

Looking forward to it.

Cheers,
David

tornado · June 12, 2009, 11:46am

Even if we are using mocks and if our models are changed then also we
need to change our spec.
Same for if we don’t use mocks.

So same question i am asking Are mocks really useful?
Also When to use if at all we want to use?
I searched on net regarding the same but till now no success

Also i had started writing controller specs without using mocks just to
see how it works?Will it be ok?

tornado · June 11, 2009, 9:02pm

On Thu, Jun 11, 2009 at 12:56 PM, David C.[email protected]
wrote:

This may be true in some cases, but generally with validations the
controller passes the params straight through to the model without
caring about them in any way. In those cases, where the controller is
only interacting with methods that are part of AR::Base, you’re not
really risking a validation change effecting the controller’s
behaviour.

This is a good point. I think I got a little too zoomed in on the
example. (In which that wasn’t entirely clear, as it did focus on
specific attributes being passed.) I stand corrected, thank you.

I run the specs after every change (using autospec). For this to work
effectively, the specs need to run fast. This is one of the benefits,
in my view, of having two separate tools for dealing at different
views of the code (i.e. RSpec and Cucumber).

And it’s why the active side project I really am spending time on
right now is a smarter, more human-efficient replacement for Autospec.

8->

But enough of that until I can actually show something for it.

–
Have Fun,
Steve E. ([email protected])
ESCAPE POD - The Science Fiction Podcast Magazine
http://www.escapepod.org

tornado · June 12, 2009, 4:46pm

On Fri, Jun 12, 2009 at 4:46 AM, Amit K.[email protected]
wrote:

Even if we are using mocks and if our models are changed then also we
need to change our spec.
Same for if we don’t use mocks.

This is true in some cases, but not in many of the common cases.
Here’s an example:

describe WidgetsController do
describe “POST create” do
context “with valid attributes” do
WidgetsController.stub(create!).and_return(true)
post :create
response.should redirect_to(widgets_path)
end

context "with invalid attributes" do
  WidgetsController.stub(create!).and_raise(ActiveRecord::RecordInvalid(mock_model(Widget)))
  post :create
  response.should render_template('new')
end

end
end

These two examples will never have to change due to a change in model
validation rules. The only reason they’d ever have to change would be
if you wanted to make a change the controller itself and how it
handles the create() action.

In this case we’re using stubs, not mocks, but they are serving the
purpose of isolating change.

So same question i am asking Are mocks really useful?
Also When to use if at all we want to use?
I searched on net regarding the same but till now no success

Amit - you don’t have to search the net. Steve, Matt and I have all
taken valuable time to try to explain this to you, and Matt even
posted some very useful links for you. From this thread, the RSpec
book, and those links, you’ve got enough information in front of you
to start answering these questions for yourself. Please take some time
to read some of this stuff. If you have any specific questions about
any of that reading material, please feel free to ask them.

Cheers,
David

Also i had started writing controller specs without using mocks just to
see how it works?Will it be ok?

You’ll be fine if you don’t use mocks. I’d be fine if I didn’t use
mocks. I happen to know how and when to use them so I like to use
them.

Cheers,
David