Should you only mock types you own?

I read through TDD: Only mock types you own entry by Mark Needham and would like to know if this is best practice or not?

Please note that he is not against mocking, but against mocking directly - he does say that writing a wrapper and mocking that is fine.

My answer is "no". You should mock anything that makes sense in the context of a given unit test. It should not matter if you "own" the mocked type or not.

These days, in a Java or .NET environment everything (and I really mean everything) can be easily mocked. So, there is no technical reason to go to the trouble of first writing extra wrapper code.

---

Some additional ideas I have been thinking about recently (November 2010), that show how illogical to "only mock types you own" can be:

1. Suppose you do create a wrapper for a third-party API, and then you mock the wrapper in unit tests. Later, however, you figure the wrapper can be reused in another app, so you move it to a separate library. So now the wrapper is no longer "owned" by you (since it is used in multiple apps, potentially maintained by different teams). Should developers create a new wrapper for the old one?!? And keep doing it recursively, adding layer upon layer of essentially useless code?
2. Suppose somebody else already created a nice wrapper for some non-trivial API and made it available as a reusable library. If said wrapper is just what I need for my specific use case, should I first create a wrapper for the wrapper, with a nearly identical API, just so I will "own" it?!?

For a concrete and realistic example, consider the Apache Commons Email API, which is nothing more than a wrapper for the standard Java Mail API. Since I don't own it, should I always create a wrapper for the Commons Email API, whenever I write unit tests for a class which needs to send e-mail?

Depends whether you mean mock or mock™…

Given you are just using a mock framework (as eg Mockito) to create stubs, then creating stubs of types you don't own is totally okay and reasonable.

If however, you are using a mock framework (as eg Mockito) to create mock™ objects, then you best literally follow the advice of the mock™ evangelists. Personally I lost touch to that movement, so I cannot tell you whether Mark Needham's advice is to be considered kosher or not.

Irony aside, what Mark writes about mocking of EntityManagers in Hibernate sounds reasonable by itself. But I doubt that we can generalize a rule like "never mock types you don't own" from that specific case. Sometime it might make sense, sometimes not.

I like the explanation the Mockito project gives to this question. > Don't mock type you don't own! > > This is not a hard line, but crossing this line may have > repercussions! (it most likely will) > > 1. Imagine code that mocks a third party lib. After a particular upgrade of a third library, the logic might change a bit, but the test > suite will execute just fine, because it's mocked. So later on, > thinking everything is good to go, the build-wall is green after all, > the software is deployed and... Boom > 2. It may be a sign that the current design is not decoupled enough from this third party library. > 3. Also another issue is that the third party lib might be complex and require a lot of mocks to even work properly. That leads to overly > specified tests and complex fixtures, which in itself compromises the > compact and readable goal. Or to tests which do not cover the code > enough, because of the complexity to mock the external system. > > Instead, the most common way is to create wrappers around the external > lib/system, though one should be aware of the risk of abstraction > leakage, where too much low level API, concepts or exceptions, goes > beyond the boundary of the wrapper. In order to verify integration > with the third party library, write integration tests, and make them > as compact and readable as possible as well.

I was going to say "no" but having had a quick look at the blog post I can see what he is on about.

He talks specifically about mocking EntityManagers in Hibernate. I am against this. EntityManagers should be hidden inside DAOs (or similar) and the DAOs are what should be mocked. Testing one line calls to EntityManager is a complete waste of your time and will break as soon as anything changes.

But if you do have third party code that you want to test how you interact with it, by all means.

IMHO, the question of ownership is irrelevant.

The relevant question is the one of coupling, i.e. what does your test code specify. You certainly don't want test code which specifies details of the API of some library that you happen to use. This is what you get when you e.g. use Mockito to mock the library directly in your test class.

A widespread solution proposal for this problem is to create a wrapper around the library and then to mock the wrapper. But this has the following drawbacks:

• The code inside the wrapper is not tested.
• The wrapper may be an imperfect abstraction, so the API of the wrapper may need to be changed. If you mocked the wrapper in many tests, you have to adapt all these tests.

So instead, I would recommend to decouple tests from interfaces in productive code altogether. Don't put the mocks into the test code directly, but create a separate stub class which implements or mocks the productive interface. Then add a second interface to the stub which allows the tests to do the necessary setup or assertions. Then you only need to adapt one class in case the productive interface changes – and you could even afford to mock/stub the interface of a library that is complex or changes frequently.

---

Note: All this is assuming that it is in fact necessary to use a mock or stub. I didn't discuss this question here because it was not in scope of the OP's question. But really ask yourself if you have to use mocks/stubs at all. In my experience, they are overused...

I agree with Mark is saying. You can not unfortunately mock everything and there are somethings you don't want to mock, just because your normal use of it is a black box.

My rule of thumb is Mock things that will make the test fast but won't make the test flaky. Remember not all fakes are the same and Mocks are not Stubs.

I'm certainly from a minority, but I regard Mocking as a Code Smell and use dependency injection instead if possible. The rationale is that mocking is basically a workaround for testing some hard to test code. Mocks weaken tests because they behave (at best) like a specific version of a library. If the library change, your test loose all it's checking value.

You can see reading the above that I'm using Mark Needham's own arguments, but not for saying you should not mock object's you don't own, but that you shouldn't Mock at all...

OK, if dependency injection is not an option, then let's mock... but then you have to understand that your test is a fake and won't behave like production code. That's not a real unit test, just a partially faked one. If possible, you can make it less so by adding tests that checks that behavior is as expected for the Mocked Objects.