Practice : Mocking and Stubbing

Purpose and Strategic Importance

Mocking and Stubbing are practices used to isolate code under test by replacing real dependencies with controlled, lightweight substitutes. This allows tests to be deterministic, fast, and focused on the logic being verified - not on the availability or correctness of external systems.

These practices improve test reliability and speed, reduce flakiness, and support better coverage of edge cases. They're essential for unit testing, integration test isolation, and safely simulating real-world conditions.

Description of the Practice

  • Mocks simulate objects or services with strict behaviour verification (e.g. call expectations).
  • Stubs provide predefined responses to allow tests to run independently of external dependencies.
  • Used to isolate code from databases, APIs, queues, and third-party systems.
  • Implemented using frameworks like Sinon, Mockito, Moq, or custom fakes.
  • Applied across unit, integration, and contract testing contexts.

How to Practise It (Playbook)

1. Getting Started

  • Identify external dependencies that make tests flaky, slow, or hard to control.
  • Use mocking/stubbing libraries for your language to simulate those dependencies.
  • Write tests that define expected inputs and verify outputs or interactions.
  • Avoid mocking the system under test - mock only collaborators or external boundaries.

2. Scaling and Maturing

  • Build shared mocks or stubs for common external services.
  • Combine stubs with contract testing to validate real interfaces.
  • Integrate mocking strategies into TDD and test review practices.
  • Manage test data centrally for reusable and predictable stubbing.
  • Use dependency injection or adapters to improve testability.

3. Team Behaviours to Encourage

  • Design code for testability by separating logic from infrastructure concerns.
  • Review mocks and stubs for accuracy and realism - avoid magical values.
  • Collaborate with API teams to align stubbed behaviour with real service contracts.
  • Use mocks to simulate failure conditions and verify system resilience.

4. Watch Out For…

  • Overuse of mocks that tightly couple tests to implementation details.
  • Fragile tests that break due to internal refactors rather than behaviour changes.
  • Inconsistent mocks across test suites leading to misleading confidence.
  • Avoiding integration entirely - use mocks thoughtfully, not exclusively.

5. Signals of Success

  • Tests are fast, reliable, and focused on behaviour.
  • External systems are simulated accurately in tests without requiring live access.
  • Failures reflect real problems, not test environment instability.
  • Developers are confident refactoring with strong test safety nets.
  • Codebases are modular and designed with testing in mind.