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

Comments

Projects
None yet
10 participants
@andreareginato
Collaborator

andreareginato commented Oct 3, 2012

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

@markburns

This comment has been minimized.

Show comment
Hide comment
@markburns

markburns Oct 3, 2012

This example uses a stub.

markburns commented Oct 3, 2012

This example uses a stub.

@mattvanhorn

This comment has been minimized.

Show comment
Hide comment
@mattvanhorn

mattvanhorn 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.

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

This comment has been minimized.

Show comment
Hide comment
@myronmarston

myronmarston 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.

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

This comment has been minimized.

Show comment
Hide comment
@urbanautomaton

urbanautomaton 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.

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

This comment has been minimized.

Show comment
Hide comment
@dchelimsky

dchelimsky 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.

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

This comment has been minimized.

Show comment
Hide comment
@myronmarston

myronmarston commented Oct 6, 2012

@urbanautomaton well said!

@dchelimsky

This comment has been minimized.

Show comment
Hide comment
@dchelimsky

dchelimsky Oct 6, 2012

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

dchelimsky commented Oct 6, 2012

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

@Spaceghost

This comment has been minimized.

Show comment
Hide comment
@Spaceghost

Spaceghost Oct 29, 2012

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

Spaceghost commented Oct 29, 2012

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

@saimonmoore

This comment has been minimized.

Show comment
Hide comment
@saimonmoore

saimonmoore Nov 22, 2012

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

saimonmoore commented Nov 22, 2012

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

@andreareginato

This comment has been minimized.

Show comment
Hide comment
@andreareginato

andreareginato Mar 9, 2013

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.

Collaborator

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

This comment has been minimized.

Show comment
Hide comment
@aTei

aTei Apr 9, 2014

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

aTei commented Apr 9, 2014

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

@dchelimsky

This comment has been minimized.

Show comment
Hide comment
@dchelimsky

dchelimsky 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 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

This comment has been minimized.

Show comment
Hide comment
@dchelimsky

dchelimsky Apr 10, 2014

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

dchelimsky commented Apr 10, 2014

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

@wmadden

This comment has been minimized.

Show comment
Hide comment
@wmadden

wmadden 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".

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