I read through this blog 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.
+1
A:
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.
cletus
2009-12-15 10:05:10
A:
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.
AutomatedTester
2009-12-15 10:06:43
Actually, you CAN mock everything.To me, the real difference is not between mocks and stubs, but between strict and non-strict expectations. And the expectations associated to any mock object can be either strict or not.
Rogerio
2009-12-17 16:10:30
+1
A:
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.
Rogerio
2009-12-17 16:15:55
A:
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.
kriss
2010-07-10 23:12:33
I think maybe your definition of either "dependency injection" or "mocking" is different that the usual. They are not mutually exclusive, rather, they are complimentary: sometimes you inject the real implementation of a dependency (production, integration testing), and sometimes you inject mocks (unit testing).
Ladlestein
2010-09-25 06:42:39
@Ladlestein: I don't believe so, but maybe. I use "Mocking" when I'm changing behavior of something that is not an explicit parameter (typically some global library). I speak of "Dependency Injection" when I'm refactoring code to replace an implicit parameter with an explicit object provided as a parameter (either through tested object constructor or of some method). And indeed when provinding some test object I do not speak of Mock any more but of Stubs (if it's not a real implementation) or of Fakes (real implementation but simplified for testing purpose).
kriss
2010-09-25 07:07:22