Allen begins with a sharp argument to what's likely the most common misconception about mocks:
Some people have a misconception that mock objects are only useful if you need to simulate interaction with a resource that is difficult to use in unit tests - like an object that communicates with an SMTP server. This isn't true.He follows with a reference to Colin Mackay's article on mocks listing some common scenarios mocks are useful:
Allen then gets to the meat of his message when he implies that even the list above may be a tad shortsighted, asserting more generally that "test doubles [mocks] are useful when you want to isolate code under test." In short, according to Allen mocks are to be used to keep the tests for business components independent of all other components the component under test is dependent on; 'A' uses 'B', 'A unit test' should break only if 'A' is broken, regardless of the condition of 'B'.
- The real object has nondeterministic behavior
- The real object is difficult to setup
- The real object has behavior that is hard to trigger
- The real object is slow
- The real object is a user interface
- The real object uses a call back
- The real object does not yet exist
The article continues with a tie-in to the role of mock objects in true test-driven development:
The authors of "Mock Roles, Not Objects" say that mocks are:Allen concludes with a short discussion about the use of mock object frameworks, such as JMock, EasyMock, and NUnit. In summary, his assertion is that mock object frameworks themselves are rather simple although effective use of them can be tricky.
"… a technique for identifying types in a system based on the roles that objects play … In particular, we now understand that the most important benefit of Mock Objects is what we originally called interface discovery".
A related discussion worth checking out just surfaced on the TDD Yahoo group, check it out at here.
Community comments
Avoiding "redundant" unit test code
by Max Weber,
Re: Avoiding
by Mike Bria,
Mocks driving design
by Danilo Sato,
Link to TDD group
by Kenrick Chien,
Avoiding "redundant" unit test code
by Max Weber,
Your message is awaiting moderation. Thank you for participating in the discussion.
In my opinion another advantage of isolating code under test is the avoidance of "redundant" unit test code. According to the above sentence " 'A unit test' should break only if 'A' is broken, regardless of the condition of 'B'. " you don't care whether or not component 'B' works correctly when unit testing component 'A'. If you don't do this kind of isolation through test doubles, you always test a part of the behaviour of component 'B' in the 'A unit test'. So the point is that you already have verified this behaviour in the unit test of component 'B'. Furthermore you have to setup the desired condition of your component 'B' in the test fixture/context of 'A unit test' once again. The redundancy grows even more if you test another component 'C' which also depends on component 'B'. Nevertheless regarding to the "anti composition axiom" you have to test the interaction between these components in form of integration tests once (and only once).
Re: Avoiding
by Mike Bria,
Your message is awaiting moderation. Thank you for participating in the discussion.
Absolutely. Thanks!
Mocks driving design
by Danilo Sato,
Your message is awaiting moderation. Thank you for participating in the discussion.
My reply was getting too long, so I wrote it in my blog:
www.dtsato.com/blog/2008/06/12/using-mocks-to-d...
Link to TDD group
by Kenrick Chien,
Your message is awaiting moderation. Thank you for participating in the discussion.
The link supplied goes to your TDD label in gmail, which I have, by coincidence, the same label in my gmail. :)
The actual link is: tech.groups.yahoo.com/group/testdrivendevelopment/