I wrote this article, unit testing with mock objects, a couple of years ago. The motivation behind it was to share some of my experiences from using mock objects when testing a service oriented interface built on top of a legacy backend system. Since then I have gained some more experience about this subject. The article is not updated however to reflect this increase in knowledge (time is a limited resource) . I’m publishing the original article and hope that it may be of interest to somebody out there. Even though I would change a great deal if I was to re-write the article, I still feel that using the Adapter pattern is a good aproach when it comes to testing business logic accessing a legacy backend system.
Reading Martin Fowler’s article Mocks Aren’t Stubs l came to realize that at the time of writing the article I was very much a mockist. I’m probably still a mockist, in my opinion mock objects is an excellent technical aid when doing TDD and I always felt that using mock objects improve my design. But having used mock objects for a while now, I can see some very clear disadvantages. Amongst other the amount of setup code needed may lead to a maintenance burden if you are not careful. If you start to experience refactoring as a painful exercise, than you probably have a problem. If refactoring is hard you will not favour change. And if you cannot change your code you end up with crap that is hard to maintain… I’ve seen this happen and I’m trying my best to avoid this pain in the future. One way of avoiding this is to start treating your test classes as first class citizens and realize that whenever you write code you have increased the maintainance burden for the system.
More to come on this subject, hopefully….