Service Stub Fidelity
How faithfully a stand-in dependency reproduces the real one's behaviour — including its errors, latency and limits — which bounds what testing against it proves.
A stub that returns a canned success for every request tests the happy path and teaches the system nothing about the dependency. Real dependencies are slow sometimes, return errors with specific shapes, rate-limit, time out, and return success with a body the documentation did not describe.
Fidelity worth building, in rough order of return: the real error taxonomy, because handling code is written against the errors you know about; realistic latency, including the occasional slow response, since timeout and retry logic is otherwise never exercised; rate limits and their headers; and stateful behaviour where the dependency has any, since a stub that accepts the same idempotent request twice with different results is testing a system that does not exist.
The way to keep a stub honest over time is to derive it from recorded real interactions and to re-verify it against the real dependency on a schedule. A hand-written stub drifts from the service it imitates, and the drift is silent until an integration that passed every test fails in production.