Our GTAC Talk evolved over an extended period, and had a lot more material than the time allowed. So, just for you Creative Chaos readers, I’m going to blog our bonus section.
Comments on the Slide Above:
If you want to mock out (‘trust’) every domain – including database on db intensive apps, the filesystem on file intensive apps, and the internet on web-service apps – tread lightly.
Steve Freeman, co-author of Mock Roles not Objects, points out that his main use of mocks is to help him discover roles and relationships between objects in his domain code, rather than speeding up external dependencies. He tends to write little integration tests to check things like that the database is hooked up correctly. (Editors note: Steve actually wrote that paragraph.)
So he’s saying use mocks for design – de-emphasizing the use for testing. Mocking out the boundaries doesn’t help you with that design decision, because you are not designing the hard boundary.
So don’t do this unless you’re testing some otherwise untestable requirement – like handling exceptions when the filesystem is full up, when it is unrealistic to fill up the real file system. (We have a slide on this on the YouTube Talk called “Mocks As Simulators”)
If you must mock out the core system, have a balanced breakfast, cover your tests somewhere else, or run the “real” tests overnight.
or run the “real” tests overnight. sums things up I think. Or at least, I say very similar things to people when talking about mocks / stubs.
-adam