[Links] Mocks

Don’t Overuse Mocks

From Andrew Trenk, in the Google testing blog:

When writing tests for your code, it can seem easy to ignore your code's dependencies by mocking them out.

However, not using mocks can sometimes result in tests that are simpler and more useful.

If you're trying to read a test that uses mocks and find yourself mentally stepping through the code being tested in order to understand the test, then you're probably overusing mocks.

Sometimes you can't use a real dependency in a test (e.g. if it's too slow or talks over the network), but there may better options than using mocks

Stop Using Mocks

From Karl Seguin's blog:

In conclusion, by their very nature, mocks are all about testing interactions.

This doesn't decrease coupling like most think. There's actually no way to create greater coupling than to us a mock - because you have to specify every possible detail of each interaction.

When you want to test interactions, which you should test, use a mock. But I guarantee you that the ratio of behavioral tests to interaction tests will be in the neighborhood of 5 to 1. Which means mocks should be in the minority.

When you can, you should always favor either stubs or the real implementation. I haven't talked about using the real implementation (again, something the .NET community avoids like a plague), but hopefully you can see how even that isn't as crazy an idea as you've been told.

This articles had a response from Darren Cauthon:

Test Isolation Is About Avoiding Mocks

From Gary Bernhardt, in the Destroy All Software blog:

This is a large part of the claim that isolated tests drive better design. Because an isolated test must set up all collaborators as mocks, the only way to reduce the mock complexity is to reduce the depth of collaboration. If we mock three levels deep, and do nothing to reduce that mock depth, then we're spending the effort to isolate without getting the benefit. If, however, we change the design to reduce coupling, then the mock depth will also be reduced, and isolation will earn its keep.

Design isn't just reflected in isolated test setup; it's magnified. Isolated tests are a microscope for object interaction.

In addition to avoiding nested mocks, I've been using fewer over time, even when I'm writing isolated tests. The old Python system I mentioned had multiple mocks per test on average. Early DAS code written under time pressure averages around one mock per test. Later DAS code is under half a mock per test. Moving into late 2013, all of Selecta's logic is tested in isolation with no test doubles at all. (That's Functional Core, Imperative Shell again.)

In a very real sense, isolated testing done test-first exposes design mistakes before they're made. It translates coupling distributed throughout the module into mock setup centralized in the test, and it does that before the coupling is even written down.

To Kill a Mockingtest

From Ken Scambler, in the technical blog of realestate.com.au:

Please don’t use mocks or stubs in tests. While they are seemingly ubiquitous in enterprise development, they have serious drawbacks, and typically mask easily fixable deficiencies in the underlying code.

They are linked to fragile implementation details, and will constantly break under routine refactoring.

What they test is almost always beside the point of what’s actually required.

Mocks and stubs attempt to provide some level of testing in the face of entangled effects in output or input, respectively. However, in practice, almost every usage can be obviated by simply writing better code; the entanglement is the problem, and mocks only allow the developer to ignore it.

When to Mock

From Robert C. Martin, in 8th Light blog:


In short, however, I recommend that you mock sparingly. Find a way to test -- design a way to test -- your code so that it doesn't require a mock. Reserve mocking for architecturally significant boundaries; and then be ruthless about it.


If you follow these heuristics you'll find that your test suites run faster, are less fragile, have higher coverage, and that the designs of your applications are better.

The Little Mocker

From Robert C. Martin, in 8th Light blog:

This article is written as a dialog between a teacher and a student. It explains the differences between:

  • Dummies
  • Fakes
  • Mocks
  • Spies
  • Stubs
  • Test Doubles

Mocks Aren't Stubs

From Martin Fowler, in his blog:



