When to use partial mocks?

Question

I'm starting to get comfortable with the idea of fakes, stubs, mocks, and dynamic mocks. But I am still a little iffy in my understanding of when to use partial mocks.

It would seem that if you're planning on mocking a service and need to resort to a partial mock then it is a sign of bad design. Is it that partial mocks are mostly for getting legacy code under test coverage?

On the flip side of this, say I am testing a class which has a Reset() method. If I have already confirmed in a separate test that the Reset() method works, and I have some functionality of the class that should end with a call to this method, is it poor test design to do a partial mock of the object and run tests against the partial mock, defining an Expectation on the Reset() method.

I currently have several tests set up in this manner, is this sort of thing going to get me in trouble later on?

Answer 1

My understanding of partial mock was that it was for mocking abstract classes, with only the abstract methods being mocked, and the existing concrete methods being left as they are?

Answer 2

Its good design, imho. What happens when somebody comes after you and changes your method, removing the call to Reset? (btw, why so much state in your objects?) You might never know they screwed up until you hit production. By mocking it and asserting on that method call, you can assure nobody is going to mess up while maintaining your code.

Answer 3

One could argue that all mocks are 'partial' in that they do not fully implement an interface. As you are trying to test a very focused piece of functionality, you should only mock those aspects of supporting classes that are necessary to exercise the piece of functionality you are testing.

This will allow your test to be decoupled from other tests, which is nice.

Answer 4

In your example it sounds like the Reset method is an implementation detail and by using a partial mock, you are in danger of coupling your test to the implementation of the class. This will make your test more brittle than it needs to be.

I also think it makes tests more confusing to have an object having some methods with real implementations and some with stub implementations. It's just one more thing to remember when you come back to a test later.

Can you either (a) use state-based testing to assert that the state of the object is as you expect after the real Reset method has been called internally; or (b) use interaction-based testing to verify that the relevant calls to collaborating objects have been made as a result of the real Reset method?

You might find Test Smell: Mocking concrete classes from mockobjects.com useful.