Particle physics, mocks and stubs
Steve Freeman had interesting analogy in TDD 10 years later (17m30s, slide 26: The origins of mock objects). He describes mocked unit test being “rather like particle physics”.
You fire something at a particle, things splinter off and you can detect what happens…
A mock is used to both detect the emissions from the system under test (SUT), and verify expectations. Additionally, a mock object may perform stub duties. This doesn’t quite fit, since fission is one-way.
Testing “by detection” like this is considered behaviour verification: verifying collaborations between the SUT and other objects.
To be testable in such a manner:
- Requires the ability to isolate the SUT sufficiently, i.e., detach it completely from its context and collaborators. A test fixture should be able to create the SUT easily by itself.
- Then the SUT should minimize concrete dependencies.
- Collaborators must be designed in such a way to allow a mock to be generated that can intercept interactions. This means identifying the abstraction(s) for collaborators.
- Mock is a stub in the sense that it needs to stand in for a real (if inert) object. But a mock is also a “detector” and is used as the means of assertion.
- Stub queries and mock actions. “we mock when the service changes the external world; we stub when it doesn’t change the external world – stub queries and mock actions”
- Mock Roles, not Objects (Steve Freeman). Define abstractions for a collaboration, leaving concrete implementations until required.
- Slides — TDD 10 years later (QCon London 2009).
- Mocks Aren’t Stubs (Fowler).