Service Virtualisation

Virtualisation earns its place when the real dependency is unavailable, expensive per call, rate limited, owned by a third party, or a mainframe that cannot support a test environment per team — which describes most enterprise integration landscapes.

The distinction from a naive mock is fidelity. A mock returns a canned success response instantly, which trains the system under test on a world that does not exist. A useful virtual service reproduces the dependency's latency distribution, error responses, rate limits and malformed edge cases, because those are exactly the behaviours the calling code handles badly.

The permanent risk is drift: the simulation encodes what the dependency did when it was recorded, and the dependency changes. A test suite that passes against a stale simulation produces confidence that is not merely useless but actively misleading.

The control is to bind the simulation to a verified contract rather than to hand-written fixtures, regenerate it from recorded real traffic on a schedule, and keep a small number of genuine integration tests against the real dependency whose job is solely to detect that the simulation has gone stale.