Mock objects – now you have two problems

Posted by robbiebow on 8 August, 2009 under geek, perl | Be the First to Comment

System testing lets you know how your code interacts with the rest of the code and environment, and across boundaries. They are more likely than unit tests to highlight deficiencies in your code although less likely to highlight the exact point (line, file) where things went wrong. Unit tests are the opposite. The two are therefore complimentary.

Recent experience of testing with mock objects involved has been painful. If you work with any reasonably complex system with many people you will not necessarily know offhand what’s being mocked at any one time: and the better the mockery the harder it is to tell it’s there at all. Trouble begins when you change a part of your system that has a corresponding mock object. And then you run the tests. And they pass. Not because your changes are good, but because you were unaware that your code is not being used but because the mock object is. Or the tests fail, because the mock object is more simple than the object it represents and doesn’t cover the scenarios you are putting it into now.

So you update the mock object(s) as well. They become bigger and more complex and more like the things they represent, which begins to beg the question, if it’s becoming more and more like the thing it replaces, why replace the thing? You’ve effectively forked your code base and are repeating yourself. And that, kids, is bad, mkay?