The key part is that you don’t actually need to build the collaborating object. In fact, you don’t need to worry at all yet about how it will be implemented. All that matters is that you express the messages it responds to, so that the mock object can test whether they’re sent. In effect, the mock lets you say, “I know that at some point I’ll want this, but I don’t want to be distracted by thinking about it.” It’s like a to-do list for TDDers.
The other way in which we can use mock objects is to investigate integration with external code, such as Apple’s frameworks or third-party libraries. The mock object can remove all of the complexity associated with using the framework, so the test doesn’t need to create a full-blown environment just to ensure a small part of our app’s connection to that environment. This use of mock objects follows a test pattern called the Humble Object.
A nice mock records the messages it receives, just like a regular mock, but it doesn’t worry about receiving messages that it wasn’t told to expect.
Partial mocks act as proxies to real objects, intercepting some messages but using the real implementation for messages they weren’t told to replace.
Stay up-to-date by subscribing to the Comments RSS Feed for this post.