Sep 21 2009
Mocks are not about isolation, but about responsibilities
Last week at CITCON Europe Steve Freeman organised a session on mock objects focusing on the original ideas and what mock objects should be used for. Freeman started by disagreeing with the established view of mock objects as isolators for unit testing, advising developers to use mocks for object design and specifying responsibilities.
According to Freeman, the original Mock object idea came out of the Roles, Responsibilities and Collaborations object design school (Rebecca Wirfs-Brock). When applying TDD to design and develop such objects, we need to specify and test responsibilities of objects, and externally visible object state isn’t part of that. Verifying that an object matches its responsibilities requires that we “fire an event and see that the appropriate messages have been sent to its collaborators”. According to Freeman, interfaces aren’t enough to specify objects because “an interface tells you what methods you can call, not when and how to call them. it doesn’t specify the contract – this is where mocks come in.”
Freeman advises using mocks as a design tool, not primarily to isolate dependencies: “To prove that this works we need a thingy but we don’t have that thingy yet, so we define it with a mock.Work your way through the slice of a system until you get to something external”. Instead of mocking out external dependencies, Freeman suggests that “you should only mock what you own”. Answering a question about the practice of mocking out database access, he said that once the system boundary is reached, developers should define the external interface in terms of their domain, providing a concrete implementation of that interface that speaks to the external system. This way the code inside a system is isolated from external dependencies and the concrete implementation should be covered by integration tests. This idea comes from Alistair Cockburn’s Ports and Adapters architecture (also called Hexagonal Architecture), where the domain we work on is in the middle and ports help it communicate with the external world. Adapters for individual ports implement the responsibility for a particular external system integration. “Test adapters with the real thing”, suggested Freeman. In domain-driven-design this corresponds to specifying a repository for objects in the context in which we work, and then providing an implementation for that repository interface that talks to a specific database or a queueing system.
Speaking about different guidelines on when to use mocks, Freeman suggested a rule of thumb “we mock when the service changes the external world; we stub when it doesn’t change the external world – stub queries and mock actions”. However he said that teams should not be enforcing rigid rules.
As some of particularly bad ideas he’s seen and experienced with mocks, Freeman said that one of the biggest mistakes was to try to mock out standard java libraries. On a controversial topic of mocking concrete classes, Freeman said that it is generally a bad idea because that means that “you care about a dependency between objects enough to mock it but you haven’t made that relationship explicit in code”. If there is no interface defining the relationship between two classes then people won’t know which of the methods of the concrete class actually participate in the relationship. An interface suggests a role, and a class might have lots of other methods there. If the interface isn’t there then the relationship is just implicit, which will make it hard to understand and maintain these objects later. “Creating an interface also forces you to find a name for it so you might discover other things that weren’t obvious”, said Freeman. Freeman also suggested locking down all dependencies in unit tests (eg making them final), which forces developers to clear up where the dependencies are and how they are used.
Freeman’s upcoming book Growing Object Oriented Software, Guided by Tests covers this topic in more detail.
 |
 |
I don’t get your last sentence. What do you mean by “locking down all dependencies in unit tests (eg making them final)”?
[...] Stub queries and mock actions. [...]
make them immutable, to force you to clearly define where they are initialised and passed to the dependent object
[...] Mocks are not about isolation, but about responsibilities – Gojko Adzic sumarises a presentation by Steve Freeman at CITCON Europe about the use of mock objects, what they were intended for originally and how you should use them. Some interesting thoughts [...]
I don’t understand the parts that say “If there is no interface defining the relationship between two classes …” and “If the interface isn’t there then the relationship is just implicit, …”.
I always thought that all classes HAVE an interface. In Java, we have four different accessibility levels (public, protected, package private/default, and private) for the members of a class.
In my understanding, the set of public members of a class C is the “public interface” of the class. So, if another class C’ in a different package uses this public interface of C, then we DO have “an interface defining the relationship between two classes”, and that relationship is very explicit.
Where is the error in this understanding?
@Rogerio,
If a class has several roles, it’s public interface is a mix of methods from all these roles. The premise here is that when one of those roles change later, as the role is not explicitly defined by a separate interface, deciding what to refactor and what to leave might be a challenge. If the role is explicitly defined by an interface, then the definition is clear. (That’s my understanding)
@gojko,
OK, in the case of a class implementing multiple interfaces because it has multiple roles, I agree with you.
The article seems to be saying that all classes should have separate interfaces, though. I don’t often create classes which have multiple roles, so most of my classes don’t implement separate abstractions. I prefer to use separate classes (and consequently separate interfaces, since each class has its own public interface) for separate roles, it seems simpler to me that way.
Hi Gojko, Nice summary! FYI, I also wrote some stuff about the role of mocks, interfaces and dependencies at the system boundary a while back — http://silkandspinach.net/2005/03/22/the-middle-hexagon-should-be-independent-of-the-adapters/