Interfaces and isolation
Roy Osherove has suggested a new name for mocks, fakes, stubs or any test double: Isolation. True, the myriad of test double names can muddy the language, and Meszaros’ suggested name of “test double” still confuses people that don’t get the “stunt double” comparison.
When I first started using mocking frameworks, before I understood the OO design techniques they were intended to support, I used primarily two methods in Rhino Mocks:
Using these two techniques of creating Mock objects and setting expectations, without good OO design, led to a lot of over-specified, brittle tests. Setting expectations that seemed to mirror the system under test seemed to be rampant duplication and hindrances to change. Over time, as I started to learn more about good OO design and the SOLID principles, the issues of brittle and over-specified tests simply went away. Techniques such as:
- Dependency inversion principle
- Interface-based design
- Command-query separation
- Single responsibility principle
- Separation of concerns
All led to better specified behavior in my tests.
Which is why the name “isolation” means nothing to me.
When I’m using interface-based design, I’m doing so not because of some innate desire to increase testability, but because I want to separate concerns and invert my dependencies. I want users of my class to know exactly what is needed for this class to operate. I employ fanatical refactoring to ensure the names and responsibilities of the classes I create are clear to the maintainers of my application.
If I employ the DIP and interface-based design, what exactly am I isolating my class from? Interfaces of which the class already doesn’t care which implementation is provided? Again, I don’t use interfaces solely to swap out a test double in a unit test, but to achieve clear separation of concerns, hone the single responsibility of the class, and invert the dependencies.
When I use Rhino Mocks in the new AAA syntax, I wind up using only three techniques/methods in 99% of cases:
to supply my class under test with any dependencies it needs to work
- Stub extension method to control indirect inputs
- AssertWasCalled extension method to verify indirect outputs
Following these rules helps me describe very clear behavior in my tests, with obvious results for those reading the tests. I don’t need to isolate when I’m already depending upon abstractions.