What HTTP error codes should QA test for in every application?

At minimum, QA should test: 400 (validation errors show correctly), 401 (expired token triggers re-auth), 403 (access denied without data leakage), 404 (custom not-found page), 429 (rate limit with retry behavior), 500 (generic error page without stack traces), 502 (bad gateway during deployments), 503 (maintenance page), and 504 (timeout handling). Beyond these, test edge cases like network failures, malformed JSON responses, slow responses, and intermittent failures that trigger retry logic.

How do I simulate HTTP errors in Playwright tests?

Use Playwright's page.route() API to intercept requests and return custom responses. For example: await page.route('**/api/**', route => route.fulfill({ status: 500, body: JSON.stringify({ error: 'server_error' }) })). This intercepts at the network level without modifying your application code. You can simulate any status code, custom headers (like Retry-After), slow responses (with delays), and even intermittent failures by tracking call counts and varying responses.

How can I test error UI components like error pages and toast notifications?

Use route interception (Playwright or Cypress) to force specific error responses, then assert on the UI. For error pages: navigate to the page, verify the correct heading renders ('Page Not Found', 'Something went wrong'), confirm no stack traces are visible, and take visual regression screenshots. For toasts: trigger the error, locate the toast via role='alert', verify it contains the error message and any action buttons (retry, dismiss). Use Playwright's toHaveScreenshot() for visual regression testing of error states.

What edge cases beyond standard HTTP status codes should QA simulate?

Five critical edge cases: (1) Network failures—connection refused or DNS errors where no HTTP response is received at all; (2) Slow responses—10-60 second delays testing timeout handling and loading spinners; (3) Malformed responses—invalid JSON, HTML instead of JSON, or empty body with 200 status; (4) Partial failures—some API calls succeed while others fail on the same page; (5) Intermittent failures—first request fails but retry succeeds, verifying retry logic works correctly. These scenarios expose bugs that standard status code testing misses.

How do I integrate HTTP error simulation tests into CI/CD?

Add error scenario tests as a dedicated job in your CI pipeline. Run Playwright or Cypress tests from a directory like tests/error-scenarios/ with an HTML reporter. Upload the test report as an artifact on failure for debugging. Use MSW or route interception (no external mock server needed), making tests self-contained. Run these tests on every pull request to catch error handling regressions before merge. Set up parallel execution across browsers (Chrome, Firefox, Safari) to verify cross-browser error handling.

Simulating HTTP Error Scenarios for QA