-
Notifications
You must be signed in to change notification settings - Fork 47
Mock
The term "Mock" has almost become an anachronistic term, carrying the baggage of multiple conflicting definitions related to test doubles.
When the term "mock" or phrase "mock out" is used today, it's typically meant to describe any kind of test double. This conflation occurred because the concept of test doubles emerged when mocking libraries began emerging in the early 2000s.
Moreover, the general-purpose popularity of mocking libraries as a way to ease test pain quickly outpaced the growth of the London-school TDD practices which had been the reason for their invention in the first place. Even today, use of the term "mock" is more likely to refer to using a library to poke holes in reality than to refer to their use as design feedback mechanisms in London-school TDD.
The term "mock" has a precise definition as well, as a specific sub-type of test double. A mock object asserts that certain invocations are made on itself, and will raise exception as soon as any unexpected interactions take place. Often, mocking libraries will adopt a record-playback metaphor in their API to facilitate this configuration, like EasyMock for Java shows below:
import static org.easymock.classextension.EasyMock.*;
List mock = createMock(List.class);
expect(mock.get(0)).andStubReturn("one");
expect(mock.get(1)).andStubReturn("two");
mock.clear();
replay(mock);
someCodeThatInteractsWithMock();
verify(mock);
There are several structural critiques one could make of this style of test:
- The
clear
andreplay
steps require every user to carry extra water for the sake of pleasing the test framework - The test must configure its expectations before invoking the subject under test, which necessarily violates Arrange-Act-Assert
- It conflates assertion (via
expect
) with stubbing (viaandStubReturn
), which explicitly verifies the implementation of the subject and not its ultimate value (i.e. if the subject can magically figure out a way to solve the problem without needing to invoke a configured stubbing, it shouldn't be punished for doing so by triggering a failure). This is an indication that the assertion is unnecessary
It was because of these issues that Test Spies became a more common alternative to mock objects, as they silently record each invocation made against themselves without requiring a record/playback metaphor, violating Arrange-Act-Assert, or raising the fear of over-asserting the subject's implementation.
This wiki was put together by your friends at test double. Come say hi!
- Test-driven development
- Test Doubles
- Refactoring Legacy Code
- Training Activities
- Additional Concepts