7

There's been a lot of talk in various blogs, forums and on StackExchange about the distinction between Mock and Stub objects (most of them specifically referencing the Rhino Mocks framework). These include posts from Martin Fowler and a chapter in Roy Osherove's "The Art of Unit Testing".

I'm currently looking at how to write more maintainable, readable tests, and in doing so have been looking at alternative isolation frameworks to Rhino. I've looked into the nSubstitute library, which just references "Substitutes" rather than "Stubs" or "Mocks". This post from Ayende suggests that he may head in a similar direction for RhinoMocks 4.0

My question is - while there seems to be a concensus about the distinciton betewen the purpose of a Mock and a Stub, is it really worth caring about? Does distinguishing between the two lead to more maintainable/readable tests, or does it just introduce unnecessary complexity?

Improve this question
2
  • 5
    Your stub will be publicly mocked, regardless of what you call it.
    – Steven A. Lowe
    Commented Apr 13, 2011 at 2:33
  • 2
    +1 after reading the examples for the nSubstitute library i was impressed how simple and clear the creation of fake objects can become compared to Rhino. May be your question should be something similar to Are we loosing anything if we dont have to care if it is a mock or a stub.
    – k3b
    Commented Apr 13, 2011 at 5:42

3 Answers 3

Reset to default
4

This question on SO gives a pretty good understanding on the difference of each. It is subtle but it is still there. In short stubs are dumb, pre-recorded set of answers for a specific test. They are not usually very re-usable and are only basic plugs to test a specific class. Mocks are smarter in that you can configure them dynamically and question them afterwards on the interactions the tested class submitted them to.

Getting this right is important if your team uses both for specific uses. Swapping the terms in this conditions will lead to some confusion about the required task : "Stub this class with limit data for your test" to me implies a different test than "mock the dependencies for your test". In the first stubs just dumbly return fake values that will allow me to test specific values. the second implies that I have to also test the interactions between the tested class and it's dependencies. Nothing prevents me though from implementing the stubs with the same mocking framework (effectively creating a dumb mock) but it is much harder to create a mock from a stub.

That said, nSubstitute seems to pretty much solve this by merging all the concepts under one address. At which point the debate is pretty much academic.

Thanks for the link :-)

Improve this answer
1
  • I like this approach. I think it's important to distinguish between behavioural and interaction-based tests, and use a "Mock" or "Stub" appropriately... but you're right, if your chosen framework merges the two, it is purely academic :)
    – mjhilton
    Commented Apr 14, 2011 at 0:03
1

Martin Fowler has a great article on the subject "Mocks aren't stubs" but he doesn't say why you should care.

Karl Seguin has a very strong opinion : "Stop Using Mocks" (Read the comments for even a better discussion)

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.

Darren Cauthon responded to Karl Seguin : "Stop Using Mocks - A Rebuttal"

What I take from this discussion, yes you should care. The choice has an affect on the brittleness of tests, the way your tests show intent and if your tests are correct.

Improve this answer
1
  • Thanks for these links - very interesting reading, and a good way to put the whole thing into some context. I love the syntax of FakeItEasy in Karl's post by the way... I sat here with my mouth open for at least 15 seconds when I saw: Any.CallTo(store).WithReturnType<User>().Returns(expected); What an elegant way to stop your tests breaking when you refactor a method in the production code!
    – mjhilton
    Commented Apr 13, 2011 at 23:52
0

I think it is worth the little extra effort. If stubs are used for inputs and mocks for outputs the tests are more clearly readable. As an added benefit you might discover some objects should be mocks and stubs (used for in- and output) which might point out an insufficient design/architecture. In my opinion this is true in my area (embedded climate control) but this might depend on the area your working in.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.