[rspec-users] How do you keep mocks updated without pain?
zach.dennis at gmail.com
Wed Aug 29 18:19:28 EDT 2007
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
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.
On 8/28/07, Priit Tamboom <priit.tamboom at eesti.ee> wrote:
> 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
> 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  suggest to write integration
> tests (what should indicate that mocks are outdated) and Ryan 
> 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.
> Priit at typical.nuby.reaction.to.mock.things
>  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."
>  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
> rspec-users mailing list
> rspec-users at rubyforge.org
More information about the rspec-users