Developers using Mock Objects aren't getting better designed code. They're following the trend of the community to use Mock Object projects without understanding the mock philosophy (sic). Using mock objects is a design technique, but Mock Objects only provide a testing technique. If people use mock objects instead of Mock Objects, their designs will improve.
In case you haven't noticed yet, I think there's two things here that need to be considered separately - "Mock Objects" and "mock objects".
"Mock Objects" (with capitals) are tools that try to automagically fake API's of 3rd party libraries which get used in Java programs. They are used as a *testing* technique. I think they are bad.
"mock objects" (without capitals) are just a way for developers to stub implementations of parts of their own code (not 3rd party libraries). Developers write the mocks themselves rather than having it generated. They are used as a *design* technique. I think they are good.
The reason I like "mock objects" is that you use them in conjunction with TDD to drive the design of your code. The code getting mocked is at least one layer in from the 3rd party libraries, so you end up with better abstractions in your code and a much cleaner design.
The reason I don't like "Mock Objects", is that you end up with complex mock behaviour (mainly because of complex 3rd party API's). It's also easy to get a bit lazy because your design is not being driven anymore.
Comments
I agree to some amount. However I think sometimes it's a good idea to mock 3rd party libraries.
How do you write a test for mapping the contents of an HttpRequest to your custom class(es), for example?
Posted by: Ilja Preuß | January 11, 2004 07:49 PM
If you're mapping contents of a HttpRequest to a custom class, it sounds to me like you've already abstracted out the presentation layer and just need to test your abstraction. Sounds fine to me.
I would have a problem if you wanted to use the Mock Objects to test passing the HttpRequest down to various objects that do more functional processing. Then the design starts to sound more sucky...
Posted by: marty | January 11, 2004 09:18 PM
Sounds like we are on the same page, then...
Posted by: Ilja Preuß | January 12, 2004 08:41 PM
I'm afraid that you have misunderstood the "mock philosophy".
Mock objects (with whatever capitalisation you want to use) are not just a way to stub code. They are used to make assertions over the OUTGOING calls of your objects, and thereby drive the design of the interactions between objects.
Mock libraries are not tools to automagically replace third party libraries. If you follow the mock objects philosophy you don't mock third party libraries except in a few rare circumstances. A mock library does not try to replace thought with automagic behaviour. A good mock object library helps maintain the rhythm of test-first programming because you can easily write assertions about the calls that the object under test will make to other objects in its environment, instead of thrashing between writing the test and writing the mock classes you need to write the test.
Posted by: Nat Pryce | January 16, 2004 01:42 AM
Nat...
I think what you just said is exactly Marty's point.
What he calls Mock Object libraries are those libraries floating around that do provide 'mock' implementations of third party libraries, not things like JMock or easyMock.
Posted by: Perryn Fowler | August 25, 2004 06:15 PM