The other day on Twitter Roy Osherove made the statement that he was teaching a class on TDD and he was showing how to use the various Isolation Frameworks. When I read this I had to ask if he talking about Mocking frameworks when he said Isolation frameworks. And indeed he was.
As I sat back to reflect on the semantic differences between the terms Mocking and Isolation I had an 'ah-ha' moment.
When we use the term Mocking we are talking about replacing the 'real' functionality with 'canned' functionality. Martin Fowler put it best in his Mock's aren't Stubs post
Mocks are objects pre-programmed with expectations which form a specification of the calls they are expected to receive.
This definition works great and makes a ton of sense, however when most people talk about mocking frameworks do not immediately think 'replace real functionality with fake functionality' they are talking about how they setup their tests to test logic in isolation.
However, when you tell someone you are working with an isolation framework the idea should click in their head as to what is going to take place and how it is going to be used. By using the term isolation framework we are telling our end users (developers) that what we are really trying to do with the framework is remove external dependencies from our test in order to make them more granular and reliable.
In fact many times when using a tool like RhinoMocks you are not setting up mocks instances but just removing actual functionality from your tests (remember not all tests need expectations setup). In these cases aren't we simply isolating behavior?
Maybe switching terms can lead to a wider adoption of mocking (sorry isolation) frameworks being part of our testing tool belts.
I know that at the end of the day a mocking framework like RhinoMocks or Moq really is setting up and executing Mocks for object instances, but I really like the idea of calling these isolation frameworks going forward.
Till next time,
[--- check out www.dimecasts.net ---]
12-09-2008 7:14 AM