Fault injection

Fault injection makes a dependency misbehave on purpose so the code that depends on it can be tested against the failures it will eventually meet: slow answers, intermittent 5xx errors, timeouts, malformed bodies. It is the controlled, repeatable end of the spectrum that runs up to chaos engineering in production.

How it works

Faults are injected at a boundary the code under test cannot see past — a mock server, a proxy, a service mesh rule, a feature flag in the dependency itself. The test then asserts on behaviour: that retries happen and stop, that a timeout fires, that a fallback is shown, that no half-written state is left behind.

The misconception

That random failures make a good test. A test that fails one run in four is a flaky test. Useful fault injection is deterministic — this request fails, that one is slow — or at least seeded, so a failure can be reproduced and a fix verified.

Try it here

The Fault Injection API is configured with PUT /faults/v1/config — latency, a status code, a failure rate, malformed JSON — and GET /faults/v1/target then misbehaves exactly as configured, inside your own sandbox.

Sources

Other terms

Flaky tests — A test that sometimes passes and sometimes fails without any change to the code it tests.
Mock API — A stand-in for a real API that returns realistic responses without the real system behind it.
API sandbox — An isolated copy of an API where calls have no real-world effect and data can be reset.
Mocks, stubs and fakes — Three kinds of test double — stand-ins for a real dependency — that differ in what they do and what they check.
Test fixture — The known data and state a test starts from, set up the same way on every run.
Contract testing — Testing that an API and its consumers agree on the shape of requests and responses, without running them together.

All glossary terms · Testing techniques · All 39 mock REST APIs

Last updated 16 October 2026