Practise vocabulary for test doubles in API testing: mock, stub, fake, spy, and the Pact-specific mock provider.
0 / 5 completed
1 / 5
A ___ is a test double that returns hard-coded responses to specific calls, without verifying how it was called.
A stub provides predefined responses to calls — it controls the indirect inputs to the system under test. Unlike a mock, a stub doesn't verify expectations about how it was called.
2 / 5
A ___ records calls made to it and allows assertions on how many times it was called and with which arguments.
A spy wraps a real or stub implementation and records interactions (call count, arguments). This allows both the return value control of a stub and the call-count assertions of a mock.
3 / 5
A ___ is a working implementation of a dependency, simplified for testing — for example, an in-memory database instead of a real one.
A fake has working business logic but is simplified compared to production — like an in-memory SQLite database instead of PostgreSQL. Fakes are functional but not suitable for production use.
4 / 5
In Pact, the ___ acts as a replacement for the real provider during consumer tests, verifying the consumer sends correct requests.
The Pact mock provider is a local HTTP server that Pact sets up during consumer tests. It responds to requests as defined in the interactions and records them to generate the pact file. It also verifies the consumer sends correct requests.
5 / 5
'Mock drift' refers to the problem where ___, making tests pass while the real API has diverged.
Mock drift occurs when mocks are not updated as the real API evolves. Tests pass against stale mocks while the real integration is broken. Consumer-driven contract testing solves this by continuously verifying the consumer's expectations against the real provider.