Test API failures: simulate slow, flaky and failing APIs

Real services fail in ways a happy-path test never sees: a slow response, a 503, a connection that drops halfway, a rate limit. If your app has never met those, you find out in production. Fault injection means making a dependency misbehave on purpose, so you can see what your code does, and fix it, before that day.

Zyvra can do this to any mock service. A fault is added to an endpoint, and it applies the next time your app calls it.

The failures you can simulate

• Latency: a fixed delay, a random range, or a throttled connection such as slow 3G.
• Errors: return a status such as 500, 502 or 503, with the body you choose.
• Dropped connections: close the connection with no answer.
• Broken bodies: cut the response off part way, or send a corrupt body.
• No answer at all: a request that never completes, to test your client’s timeouts.
• Rate limits with a Retry-After header, to test backoff.

Control when it happens

Chaos that you cannot control is hard to test with. A fault can apply:

• to a share of requests (say one in four),
• to every 3rd request, or only the first 3,
• or only to requests that ask for it with a header, for example x-chaos: slow. Normal calls to the same endpoint are not affected, so one mock can serve both your tests and a person clicking around.

Because a schedule like “every 3rd” is the same every time, a failing test fails every time, which is what you want when you are fixing it.

Ready-made situations

You do not have to build common cases by hand. Zyvra includes situations such as Slow 3G, a flaky mobile connection, fails three times then works (to test retries) and goes down after five requests.

For anything else, write it in a few lines of JavaScript: an outage that comes and goes, a quota per API key, a slowdown that grows. Scripts only run in projects you trust.

A walk-through

1. Mock the dependency: GET /payments/{id}. See Mock API server.
2. Open the endpoint’s Faults tab and add a fault: error 503 on every 3rd request.
3. Run your app against the mock, or run its tests. Watch what it does on the third call.
4. Open Traffic to see every request, what was returned, and which rule and scenario handled it.

Put it in your tests

Faults work the same when the mock runs in CI, so a pipeline can check that your client retries and times out correctly. See API tests in CI.

See Faults in the docs for every option.