Mocking and service virtualisation

A test double is anything standing in for a real dependency. Three kinds get confused constantly, and the distinction is useful.

A stub returns canned answers. Ask it for a payment result, it says success. It has no opinion about how it was called.

A mock also asserts on the interaction. It fails the test if the call was not made, or was made with the wrong arguments.

A fake is a working lightweight implementation. An in-memory database, or a payment service that actually tracks balances.

Service virtualisation is the same idea at service level: a running process pretending to be a third party, with configurable responses, latency and failures. WireMock and Mock Service Worker are the common tools.

The terms you will hear

• Test double. The umbrella term for stubs, mocks, fakes and spies.
• Stub. Returns a fixed response.
• Mock. Verifies how it was called, as well as responding.
• Fake. A real but simplified implementation.
• Spy. Records calls without changing behaviour.
• Service virtualisation. A configurable stand-in service, over HTTP.
• Drift. The double and the real dependency no longer agreeing.

What to double, and what not to

Double these: third parties you do not control, anything charging money, anything slow, anything with rate limits, anything that cannot produce the failure you need on demand.

Prefer real for these: your own database in integration tests, your own code, anything where the double would end up reimplementing the logic under test.

The test to apply: if the double has to contain business rules to be useful, you are about to test the double. Use a fake or the real thing instead.

The drift problem

A double is a snapshot of your understanding of a dependency. Dependencies change.

For example, a payment provider adds a required field, or starts returning null where it used to return an empty array, or changes an error code. Your stub keeps returning the old shape. The suite stays green. Production breaks.

Three defences, in order of cost:

• Contract tests with the provider, where the provider participates. The strongest option, covered in contract testing.
• A small scheduled suite against the real sandbox. Cheap, and it catches shape changes within a day.
• Recorded real responses used as the stub payloads, refreshed on a schedule so the drift is visible in a diff.

How to use doubles well

1. Double at the boundary, not inside. Intercept the HTTP call, rather than replacing your own client class. Then your own code stays under test.
2. Use real recorded payloads. A hand-written stub body reflects what you assumed. A recorded one reflects what the service said.
3. Simulate the failures you care about. Timeout, 500, 429 with a retry-after, malformed JSON, slow response. These paths are where real incidents come from and they are almost never tested.
4. Assert on the call where it matters. For a payment, verifying the amount and the idempotency key were correct is the point of the test.
5. Keep one fake rather than many stubs where behaviour matters. A small in-memory payment fake that tracks balances beats forty stubbed responses.
6. Refresh the payloads on a schedule, and treat a diff as a change worth reading.
7. Never let a double decide a release. Keep the scheduled real-sandbox suite, per determinism.

A worked setup

For example, here is the payment dependency handled properly.

The two details worth stealing: assertions on the request as well as the response, and recorded payloads with a date on them so drift shows up as a diff.

How to show you know it

• A failure matrix. Timeout, 500, 429, malformed. Most suites have none of these, and incidents come from exactly there.
• A request assertion. Checking the amount and the idempotency key demonstrates you understand what a mock is for.
• A drift story. "The provider made a field nullable and our stub did not, so here is the nightly suite that now catches it."
• A fake you chose over stubs. Explaining when behaviour matters more than a canned response is the senior distinction here.