Mock API vs Real API: When to Use Each in QA
When to mock an API and when to hit the real one — the tradeoffs around speed, realism, flakiness, and cost, plus the patterns that keep both honest.
· 7 min read
Should this test hit a mock or the real service? It is one of the most common questions in QA and the answer is rarely 'always one'. Each has a place, and the teams that pick correctly per layer ship faster and chase fewer phantom failures.
When to mock
Mock when the dependency is slow, expensive, rate-limited, or controlled by someone else. Third-party payments, SMS providers, geocoding APIs, and partner integrations are textbook cases — you do not want a flaky vendor or a per-request charge to break your CI pipeline.
Mock also for failure paths. Reproducing 'the upstream returned 503 with a malformed body' is trivial in a mock and almost impossible against the real service.
When to use the real API
Use the real API for contract verification — does the response still match what we expect? Mocks drift. The most painful production incidents come from a mock that says 200 OK while the real provider quietly changed its schema six months ago.
Use the real API in end-to-end smoke tests against a sandbox environment, in nightly runs that are allowed to be slower, and in pre-release verification.
The hybrid pattern that works
Most strong test pyramids look like this: unit and component tests use mocks for everything external. Integration tests use mocks for third parties but the real internal services. End-to-end tests run against a sandbox of the real provider whenever one is offered. A separate contract-test job (Pact, schemathesis) runs against the live provider on a schedule and screams the moment the schema drifts.
Keeping mocks honest
Generate mocks from the provider's OpenAPI or GraphQL schema rather than hand-writing them. Tools like Prism, MSW, WireMock, and Mockoon can serve mocks straight from a spec, so when the spec updates the mocks update with it.
Pin a real-response capture as the source of truth for non-trivial bodies. Re-record periodically against the sandbox. A captured-then-replayed mock is far more honest than one a developer typed by hand.
Test data either way
Whether you mock or call the real API, the request bodies, headers, and IDs are the same. Keep them in TestAssets so a single source of truth feeds your mock fixtures, your manual exploration in Postman or Bruno, and your CI assertions.