Standards for Mock Objects

Question

In Roy Osherove's book [Unit Testing][1] book, he explains that a single unit test should contain between 0 and 1 mocks. He suggests that if your test isn't asserting on the mock, then don't use a mock at all. He further demonstrates how to use an isolation framework to produce stubs, which were created similarly to the mocks. He places no suggested limit on the number of stubs created per test.

My question is this: can those recommendations be applied to all isolation frameworks (or all popular C# frameworks)? In other words, is there a framework that can generate only mocks - not stubs? Is there an isolation framework that does not distinguish mocks from stubs?

I'm just curious how easy Osherove's recommendations can be converted into coding standards.

[1]: http://the system under test isn’t even being tested at all, instead data returned from mocks is what is being tested.

Answer 1

There are frameworks like Moq that does not distinguish them. FakeItEasy goes even further and calls everything fake objects.

Yes, they can be applied, because mocks are just smarter stubs. It does not matter that much if stub gets called as mock as long as You don't assert on more than one mock. That recommendation in other words is more about asserting only one thing per test. Explicitly distinguishing mocks and stubs isn't that important.

Answer 2

This corresponds directly to Osherove's recommendation that you only perform one assert per test. In his lexicon a stub is a class which provides fake input to the system under test, while a mock is a class which allows you to test output from the system under test (using a fake class).

Whether a framework uses a similar naming convention is up to its designers, but the standard (if you agree with his recommendation) should be that only one assert is performed per test, and where the assertion requires a fake object - that only one fake object should be tested per test.

Of course, not everyone agrees with his recommendation, so not everyone does it this way.

Answer 3

Philip Calçado recently wrote about this: http://fragmental.tw/2010/12/14/one-mock-per-test-considered-not-awesome/. In short, he says that focusing on how many mocks/stubs there are in your test diverts you from what should be the main concern: writing good specifications.

Answer 4

> can those recommendations 
> [a single unit test should contain between 0 and 1 mocks] 
> be applied to all isolation frameworks ?

I think: Most of the time Yes if you assume these definitions

• Unittest = Test in isolation (else it is not a Unittest)
• One Unittest for one feature
• a stub or fake is an object to allow isolation but that has no verification function and
• a mock is a stub with extra functionality that also allows verification

Answer 5

i use Moqfor my Mocking Get it here

I'm not sure what exactly you mean about "stubbing", but I assume it's probably something like Moles from Microsoft which is pretty cool. Here

Both are really interesting and very easy to use.

Answer 6

This sort of rule should be seen as "Training Wheels". Obviously, a test that includes many stubs and mocks has lost the plot, but insisting on one assertion or expectation per test is just too restrictive. As the referenced Calçado link points out, what matters is that there's one concept per test, which might involve a few assertions or expectations to make the point. The last thing you should do is enforce such a standard.

One more thing, we really should be talking about "expectations" here, individual interactions, rather than entire mock objects. In practice, they're often the same, but it blurs the concepts.

Answer 7

I use Rhino mock for my test in C#. You can generate mocks or stubs with it. I encourage you to have a look on this framework: http://www.ayende.com/projects/rhino-mocks.aspx