rspec users - Aug 2007 - How do you keep mocks updated without pain?

Hi!

I know you must be answering a lot of basic questions, sorry about that :-)

However I have not get it, how do you keep mocks updated without pain?

I reached to the point where mocking things for view. I spec
model-controller-view using "correct doc" way mocking-stubbing (plus I
should run integration test to be sure that everything really works
together).

Now, when I want to change something in model then basically I have to
change mocks so many places, haven''t I? It really feels a little too
messy for me as nuby rspecer. Or it''s just my worry and you have to be
so good that you don''t have to change things too much after specing
them? If so then I know that I should think much more when mocking(=designing)
things.

When I googled about this topic I have found similar worries out there
and I got two solutions, where David [1] suggest to write integration
tests (what should indicate that mocks are outdated) and Ryan [2]
suggest to fall bact to fixtures.

I feel I will fall back to fixtures, so no more designing fun with
mocks but things feels more lightweight and practical :-) Or perhaps
it''s more up to project size and conditions... I don''t know
yet.

Oki,
Priit at typical.nuby.reaction.to.mock.things

[1] http://blog.davidchelimsky.net/articles/2006/11/06/view-spec-tutorial
"Now the risk here is that you could build a model that doesn''t
have a
title field in it and your app will blow up! Admittedly, if you only
write isolated, granular specs like this that risk is real. So you
should be doing this in conjunction with integration testing."

[2] http://railsforum.com/viewtopic.php?id=6528
"I took the past few hours and removed nearly all mocks from my specs.
I also merged the controller and view specs into one using
"integrate_views" in the controller spec. I am also loading all
fixtures for each controller spec so there''s some test data to fill
the views.

The end result? My specs are shorter, simpler, more consistent, less
rigid, and they test the entire stack together (model, view,
controller) so no bugs can slip through the cracks.

I''m not saying this is the "right" way for everyone. If your
project
requires a very strict spec case then it may not be for you, but in my
case this is worlds better than what I had before using mocks. I still
think stubbing is a good solution in a few spots so I''m still doing
that."

On 8/28/07, Priit Tamboom <priit.tamboom at eesti.ee>
wrote:
> Hi!
>
> I know you must be answering a lot of basic questions, sorry about that :-)
>
> However I have not get it, how do you keep mocks updated without pain?
>
> I reached to the point where mocking things for view. I spec
> model-controller-view using "correct doc" way mocking-stubbing
(plus I
> should run integration test to be sure that everything really works
> together).
>
> Now, when I want to change something in model then basically I have to
> change mocks so many places, haven''t I? It really feels a little
too
> messy for me as nuby rspecer. Or it''s just my worry and you have
to be
> so good that you don''t have to change things too much after
specing
> them? If so then I know that I should think much more when mocking(=>
designing) things.
>
> When I googled about this topic I have found similar worries out there
> and I got two solutions, where David [1] suggest to write integration
> tests (what should indicate that mocks are outdated) and Ryan [2]
> suggest to fall bact to fixtures.
I guess that each approach has its cons and pros.

The integration test way is the way to go, surely.
Fixtures are really a pain to maintain, and a lot of times you have
records in there that exist just because you need them to one spec.

David''s comments on integration testing is right on. The trick with
mocks is to understand when to use them, and what advantages they give
you.

Mocks allow you to test the expected interaction between the object
you are testing an some other object. This works great in TDD because
while you''re implementing an object, the object(s) it interacts with
doesn''t have to exist. You can create them as you need them.

What mocks fail to do is test the true interaction of real objects.
And that is because they are not intended to do so. They are intended
to allow you to achieve a better level of unit testing. If I am
testing ObjectA I want to know it works as expected. I don''t care
about ObjectB, ObjectC or ObjectD in my tests for ObjectA.

So integration tests give you the ability to test real objects
together. Integration tests are usually at a much higher level (not as
detailed as unit tests) and they verify that you can step through your
application as expected.

If someone renames a database column and they do not update the tests
then an integration test will catch it (if a unit test doesn''t)l. And
after seeing it fail you are reminded that you need to go update your
tests for that change.

In rspec, controller, model and view specs are just unit tests/specs.
Google around for mocks and stubs. I don''t think Martin
Fowler''s page
on "Mocks aren''t stubs" is a very clear form of explaining
mocks, so
I''m not going to recommend it with a link. If you happen to read it
then that is a plus, but if you''re just starting out with mocks it may
not be the best starter resource.

HTH,

Zach Dennis
http://www.continuousthinking.com
http://www.atomicobject.com





On 8/28/07, Priit Tamboom <priit.tamboom at eesti.ee>
wrote:
> Hi!
>
> I know you must be answering a lot of basic questions, sorry about that :-)
>
> However I have not get it, how do you keep mocks updated without pain?
>
> I reached to the point where mocking things for view. I spec
> model-controller-view using "correct doc" way mocking-stubbing
(plus I
> should run integration test to be sure that everything really works
> together).
>
> Now, when I want to change something in model then basically I have to
> change mocks so many places, haven''t I? It really feels a little
too
> messy for me as nuby rspecer. Or it''s just my worry and you have
to be
> so good that you don''t have to change things too much after
specing
> them? If so then I know that I should think much more when mocking(=>
designing) things.
>
> When I googled about this topic I have found similar worries out there
> and I got two solutions, where David [1] suggest to write integration
> tests (what should indicate that mocks are outdated) and Ryan [2]
> suggest to fall bact to fixtures.
>
> I feel I will fall back to fixtures, so no more designing fun with
> mocks but things feels more lightweight and practical :-) Or perhaps
> it''s more up to project size and conditions... I don''t
know yet.
>
> Oki,
> Priit at typical.nuby.reaction.to.mock.things
>
> [1] http://blog.davidchelimsky.net/articles/2006/11/06/view-spec-tutorial
> "Now the risk here is that you could build a model that
doesn''t have a
> title field in it and your app will blow up! Admittedly, if you only
> write isolated, granular specs like this that risk is real. So you
> should be doing this in conjunction with integration testing."
>
> [2] http://railsforum.com/viewtopic.php?id=6528
> "I took the past few hours and removed nearly all mocks from my specs.
> I also merged the controller and view specs into one using
> "integrate_views" in the controller spec. I am also loading all
> fixtures for each controller spec so there''s some test data to
fill
> the views.
>
> The end result? My specs are shorter, simpler, more consistent, less
> rigid, and they test the entire stack together (model, view,
> controller) so no bugs can slip through the cracks.
>
> I''m not saying this is the "right" way for everyone. If
your project
> requires a very strict spec case then it may not be for you, but in my
> case this is worlds better than what I had before using mocks. I still
> think stubbing is a good solution in a few spots so I''m still
doing
> that."
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>

On 8/29/2007 6:19 PM, Zach Dennis wrote:
> In rspec, controller, model and view specs are just unit tests/specs.
And that''s really the key; in Rails Test::Unit, model tests are unit 
tests, and controller tests are higher-level "functional" tests.  So
you
never get to unit-test your controllers.  On the other hand, in RSpec 
through 1.0.8, you never get to integration-test anything at all.  But 
that''s all changing!

Jay