Mock vs stub
A stub returns pre-defined responses to method calls without assertions; a mock additionally asserts that specific calls happened with specific arguments. Stubs answer 'what does the dependency return?'; mocks answer 'did the code under test interact with the dependency correctly?'. Each has its place; over-mocking is the common pitfall.
The over-mocking pattern: every dependency is mocked with strict expectations on the call signature. The result is tests that pass when the implementation matches and break when it changes — even when the new implementation is correct. Such tests verify implementation details rather than behaviour, raising refactor friction without raising confidence. The healthier discipline: stub the dependencies whose return values matter to the code under test; mock only the dependencies whose interaction itself is the contract being tested (the email service was actually called, the audit log entry was actually written). Most tests want stubs, not mocks.
Related terms
- Test double
A test double is any object that stands in for a real dependency in a test — mock, stub, fake, spy, dummy.
- Test fixture
A test fixture is the prepared state required to run a test — input data, mocked dependencies, configured environment, seeded database rows.
- Test isolation
Test isolation is the property that each test runs independently — no shared state, no execution-order dependency, no side effects bleeding to the next test.