Alan says you don’t have to use mocks for testing. “No, no, no!” he says. “If you never tested any collaborations with live objects, your rapid feedback test suite had limited use.”
That’s true; you don’t have to use mocks for testing – but try doing test / behaviour-driven design without them. It’s my fault; instead of writing “unit test or design” I should have put “unit test (read: design)”.
This is why I dislike the word test, though. As soon as the word test appears, everyone has a natural gravitation towards testing code after it’s been coded. Even though Alan is a very intelligent and imaginative developer who I know knows better than this, he still thinks instinctively of testing as being something which merely ensures that nothing’s broken. After all, you can’t test code before it’s been coded, can you?
Well, you can certainly write the test. The code will naturally follow – but this is why you have to mock out all the tools; because you haven’t got around to coding them yet. The functional or integration tests take care of the class interactions.
If you’re using JBehave’s StoryRunner to drive the functionality, then the functional tests (read: higher-level designs) all start out with mocks too!