Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Mock or not to mock #9

Open
andreareginato opened this issue Oct 3, 2012 · 14 comments
Open

Mock or not to mock #9

andreareginato opened this issue Oct 3, 2012 · 14 comments
Labels

Comments

@andreareginato
Copy link
Collaborator

@andreareginato andreareginato commented Oct 3, 2012

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

@markburns
Copy link

@markburns markburns commented Oct 3, 2012

This example uses a stub.

@mattvanhorn
Copy link

@mattvanhorn mattvanhorn commented Oct 3, 2012

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

@myronmarston
Copy link

@myronmarston myronmarston commented Oct 3, 2012

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
Copy link

@urbanautomaton urbanautomaton commented Oct 4, 2012

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
Copy link

@dchelimsky dchelimsky commented Oct 6, 2012

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.

@myronmarston
Copy link

@myronmarston myronmarston commented Oct 6, 2012

@urbanautomaton well said!

@dchelimsky
Copy link

@dchelimsky dchelimsky commented Oct 6, 2012

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

@Spaceghost
Copy link

@Spaceghost Spaceghost commented Oct 29, 2012

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

@saimonmoore
Copy link

@saimonmoore saimonmoore commented Nov 22, 2012

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

@andreareginato
Copy link
Collaborator Author

@andreareginato andreareginato commented Mar 9, 2013

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
Copy link

@aTei aTei commented Apr 9, 2014

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

@dchelimsky
Copy link

@dchelimsky dchelimsky commented Apr 9, 2014

@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
Copy link

@dchelimsky dchelimsky commented Apr 10, 2014

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

@wmadden
Copy link

@wmadden wmadden commented Jan 30, 2018

"Mock or not to mock" is advice which, in the context of a list of best practices, probably does more harm than good since it doesn't actually state what the reader should - or shouldn't do. All it does is instil a sense of unease in the reader regarding mocks. And, as others have already pointed out, it has nothing to do with speed.

A much better piece of advice would be "use verifying doubles".

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
10 participants