Service Virtualization
Replacing a real external service with a simulated one that speaks the same protocol over the network, so tests can run without the real dependency and can reproduce its failures on demand.
Service virtualization replaces a real external service, such as a payment provider, a partner's API, or another team's microservice, with a simulated one that responds over the network the same way. The code under test makes real HTTP or RPC calls; they just go to a stand-in that returns prepared responses. It's the network-level counterpart of an in-code Test Double.
The need arises because real dependencies are inconvenient to test against:
- Availability. The service may be down, rate limited, or not built yet.
- Cost and side effects. Calls may charge money, send email, or change real data.
- Control. It's hard to make a real service return a specific error, a slow response, or an unusual edge case on demand.
- Speed and stability. Network calls make tests slow and flaky.
A simulated service fixes all of these. Tests can run offline and in parallel, and they can exercise failure paths like timeouts, malformed responses, and 500 errors that are almost impossible to trigger against the real thing.
Several approaches exist:
- Stub servers like WireMock run as separate processes and match requests to canned responses, configured in code or files.
- In-process interception tools such as Mock Service Worker in JavaScript catch outgoing requests inside the test or browser itself, so application code is unchanged.
- Record and replay captures real traffic once, then serves it back.
- Commercial virtualization platforms simulate whole enterprise systems, including mainframes and message queues, with stateful behavior.
The central risk is drift. A simulation reflects what someone believed the real service did when it was written. When the real service changes, the simulation doesn't, and tests keep passing against behavior that no longer exists. Strategies to manage drift include:
- Contract tests, which check both sides against a shared expectation of requests and responses; see Contract Testing.
- Schema validation, generating simulations from an API specification so they can't return impossible shapes; see JSON Schema.
- Periodic checks against the real service, at least in a smaller suite or a Staging Environment.
Over-reliance on virtualization can also hide integration problems: authentication, network configuration, serialization quirks, and real latency only appear against the real thing. Most teams combine simulated services for fast, comprehensive tests with a few real end-to-end checks; see Integration Test and End-to-End Test.
Simulated services also support development, not just testing. Frontend developers can build against a mock API before the backend exists, and demos can run without network access. And they make chaos-style experiments safer: a simulated dependency can inject latency or failures to show how the caller copes; see Circuit Breaker and Chaos Engineering.
See also2
OpenAPI
A standard, machine-readable format for describing HTTP APIs, listing every endpoint, parameter, and response shape, from which tools generate documentation, client libraries, mock servers, and tests.
Web Platform11 connections
Dependency Injection
Passing a component the things it depends on instead of letting it build them itself, which decouples code and makes it easy to substitute fakes in tests.
Testing & Verification6 connections
Linked from12
- Chaos EngineeringTesting & Verification
Deliberately breaking parts of a running system to prove it survives failures that will eventually happen anyway.
- Circuit BreakerNetworks & Distribution
A circuit breaker stops calling a failing dependency, converting slow repeated failures into a fast, cheap one.
- Contract TestingTesting & Verification
Verifying that a service and its consumer agree on an interface's shape, without either side needing the other running to test against.
- Dependency InjectionTesting & Verification
Passing a component the things it depends on instead of letting it build them itself, which decouples code and makes it easy to substitute fakes in tests.
- End-to-End TestTesting & Verification
A test that drives the whole running system the way a user would, from the interface down through every real dependency, buying the most confidence at the highest cost.
- Flaky TestTesting & Verification
A test that passes and fails on identical input, and the most corrosive thing a suite can contain.
- OpenAPIWeb Platform
A standard, machine-readable format for describing HTTP APIs, listing every endpoint, parameter, and response shape, from which tools generate documentation, client libraries, mock servers, and tests.
- Record and ReplayTesting & Verification
Capturing real network responses once and replaying them in later test runs, which makes tests fast and deterministic but lets the recordings drift from the real service.
- Staging EnvironmentTesting & Verification
A copy of production where changes are deployed and checked before they reach real users, and why the differences between staging and production keep letting bugs through.
- Test DoubleTesting & Verification
A stand-in for a real dependency during a test — and the ways a stand-in can lie.
- Test IsolationTesting & Verification
The property that each test passes or fails on its own, regardless of which other tests run, in what order, or in parallel.
- TimeoutNetworks & Distribution
The limit on how long to wait for a remote call, the most basic defense against a hung dependency, and the harder problems of choosing the number and passing the remaining time down a chain of services.