advanced 2 min answer

A platform integrates with hundreds of external providers, and testing against them is slow, unreliable and sometimes impossible. What is the approach?

plaidvirtualisationmocksdriftcontract
Show the full answer Hide the answer

The approach

Virtualise the providers — a simulated version responding as the real one does — for the overwhelming majority of testing, with a small set of tests against the real thing.

Testing against real providers at any volume is unacceptable: it is slow, rate-limited, non-deterministic, occasionally costs money, and for some operations is not reversible.

The property that determines whether it works

Fidelity, and specifically whether the virtual service drifts from the real one. A fake that has drifted is worse than no fake at all, because tests pass while the real integration fails — producing confidence rather than caution.

The mitigations:

  • Build the virtual service from recorded real interactions rather than from documentation, since provider documentation is frequently incomplete and occasionally wrong about its own error codes.
  • Contract tests between the virtual service and the real one, run periodically against the provider's sandbox, so drift is detected automatically rather than discovered in production.
  • Re-record when the provider changes, which requires knowing when they change — a monitoring problem rather than a testing one.

What the virtual service must simulate

Not just the happy path. The failure modes are the reason the integration is difficult: timeouts, slow responses, rate limiting, malformed payloads, success responses containing an error body, and the ambiguous case where a request may or may not have taken effect.

The unknown-outcome case is the one most worth simulating, because it is the category most systems omit and the one that causes duplicates.

The small set of real-provider tests

A periodic smoke test against each provider's real or sandbox endpoint, verifying that the integration still works and that the provider has not changed. It is not part of the blocking pipeline — it runs on a schedule and alerts.

That separation is what allows the pipeline to be fast and deterministic while still detecting provider drift, which is the combination the strategy exists to achieve.