What tools can I use to simulate specific HTTP error codes for testing?

For unit and integration tests, use MSW (Mock Service Worker) to intercept requests and return any status code with custom headers and bodies. For ad-hoc testing, use HttpStatus.com's mock endpoints or tools like json-server with custom middleware. For network-level testing, use Toxiproxy to inject latency, timeouts, and connection failures. For microservice testing in Kubernetes, use Istio fault injection to abort or delay a percentage of requests.

How do I test that my client handles 502 Bad Gateway correctly?

A 502 often returns HTML (from the proxy's error page) instead of JSON. Mock the response with Content-Type: text/html and an HTML body. Verify your client doesn't crash when trying to parse non-JSON responses, shows an appropriate error message, and optionally retries since 502 is often transient. Use MSW to return: new HttpResponse(' 502 Bad Gateway ', { status: 502, headers: { 'Content-Type': 'text/html' } }).

What is Toxiproxy and when should I use it instead of MSW?

Toxiproxy is a TCP proxy that sits between your client and server, injecting network-level failures: latency, bandwidth limits, connection timeouts, and connection resets. Use it when you need to test scenarios that application-level mocks can't replicate — partial responses, slow drip connections, mid-transfer disconnections. MSW is better for testing specific HTTP responses (status codes, headers, bodies) while Toxiproxy tests network resilience.

How do I test retry logic that depends on the Retry-After header?

Create a mock that returns 503 or 429 with a Retry-After header for the first N requests, then returns 200 on subsequent requests. Track the request count in your mock handler. Verify your client waits the specified duration before retrying, makes the correct number of retry attempts, and ultimately succeeds when the server recovers. Use fake timers in your test framework to avoid real delays.

Should I run chaos engineering tests in production?

Start with staging environments that mirror production. Once your team has confidence in error handling and observability, graduate to production chaos testing with strict guardrails: limit the blast radius (affect only a small percentage of traffic), have automatic rollback if error rates spike beyond thresholds, run during business hours with the team monitoring, and start with read-only endpoints before testing write paths. Tools like Istio make this safe with percentage-based fault injection.

Simulating Server Errors for API Testing