|Robin Morris' site|
|home archives blogs collaborative book forum news feeds submit search user account|
rozzamozza 18/05/2007 - 06:47 Mocks suck because...
1. I've seen many mock tests cases pass marvoulously but the real thing falls flat on its face with a null pointer etc. Always use the REAL code whenever you can as there is no substitute.
2. It's a waste of code. Stick to real code and assertions and dont waste compile time on fake or mock objects.
3. They don't work well with refactoring. Mock Objects in particular does not refactor well. So if you chnage the method name of one of your interfaces to be more meaningfull (using a sensible IDE like intellij or eclipse) the test fails! Why? Not because of any falied answer you are expecting but because it uses reflection to rename the method.
Easy Mock or others are better at refactoring but still expect methods to be called in a particualr order or a particular number of times. Design your tests around outcomes (i.e. what the client wants from given inputs) then you should not need mocks at all.
4. You end up spending most of your tests calling the mock! I've seen this a thousand times where all you end up testing is that the methods are called in the right order.
5. If you start with Test Driven Devt you should not need to use mock except in the case of external or network dependant resources. E.g. you may wish to mock out an FTPServer to see how to handle external failure scenarios. Certainly dont mock out other useful classes. what you want your tests to do is test that your code works coherantly TOGETHER as a whole. Most people can get a class to do what they want, but during testing you are trying to weed out the unforseen consequences of knitting these classes together.