Mock or not to mock #9

Open
andreareginato opened this Issue Oct 3, 2012 · 13 comments

Projects

None yet

9 participants

@andreareginato
Collaborator

Write your thoughts about the "mock or not to mock" best practice.

@markburns

This example uses a stub.

@mattvanhorn

Mocks aren't stubs.
There is no need for the call to 'with' since you are just stubbing 'where', not setting an expctation.

@myronmarston

My thoughts:

http://myronmars.to/n/dev-blog/2012/06/thoughts-on-mocking

Mocks are super, super useful if you understand and use them well. I think it's hard to use them well in rails, though; the framework encourages you to have giant classes with huge interfaces. They need to be used as a design tool (and they work wonderfully in that role).

I also think rspec-fire is incredibly awesome. I use it on all my projects these days, and it gives me an extra safety net when I refactor or rename a method.

@urbanautomaton

Using test doubles doesn't mean you aren't testing "real behaviour" - it means you're only testing the behaviour of the subject under test. It means you're controlling the inputs to your SUT, and testing it in isolation from its real collaborators.

In doing so you gain useful design feedback about your object's collaborators (because you're forced to go through the hassle of representing them as doubles), discouraging coupling. You are able to make explicit the patterns of communication between your objects, improving your understanding of the way your objects interact, instead of just the values they compute. Even the simple necessity of getting your doubles into the SUT improves your design, because it encourages you to remove hard dependencies from your objects.

The use of test doubles is also not about fast tests, and spork is not a replacement for mocking. Spork is a kludge to get around the unfortunate fact that Rails forces your business objects to load the whole framework before they'll do anything. Fast tests are a happy side-effect of testing your objects in isolation from the behemoth that is Rails, but they are not the reason for using test doubles.

It's all very well saying "this section is opinionated", but a site that purports to represent a set of "best practices" really ought to fairly represent why and how test doubles are used before admonishing readers to avoid them.

@dchelimsky

What @mattvanhorn said - there is at least one other example of a stub on this site which you've labeled "mock". The Fowler article he referenced should help clarify the difference for you.

@dchelimsky

Also what @myronmarston said, about what @urbanautomaton said :)

@Spaceghost

What @dchelimsky said about what @myronmarston said about what @urbanautomaton said. :)

@saimonmoore

@andreareginato what @Spaceghost said and btw the site still hasn't been updated with this wisdom ;)

@andreareginato
Collaborator

Added a comment linking the @myronmarston article and explaining in a couple of rows the need to knwo them really well before using them. Any correction and comment to the updated guideline is appreciated.

@aTei
aTei commented Apr 9, 2014

Why used before {} instead of before :each? Documentation says nothing about before without parameter (:each / :all).

@dchelimsky

@aTei the docs leave out the fact that :each is the default. I'll patch that later today, unless you'd like to get involved and submit a PR to https://github.com/rspec/rspec-core yourself.

@dchelimsky

@aTei actually, the docs are all updated in master already for the rspec-3 release.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment