Testing Error and Timeout Scenarios

Real users often experience network problems such as timeouts, slow responses or server errors. Testing how your application behaves under these conditions is crucial for resilience, and Playwright’s network controls make this practical.

Simulating Errors and Timeouts #

By intercepting requests, you can force error responses, delays or dropped connections. This lets you verify that the UI shows appropriate messages and that retry logic works as intended.

// error-timeout-scenarios.spec.ts
import { test, expect } from '@playwright/test';

test('shows error when orders API fails', async ({ page }) => {
  await page.route('**/api/orders', async route => {
    await route.fulfill({
      status: 500,
      contentType: 'application/json',
      body: JSON.stringify({ message: 'Internal server error' }),
    });
  });

  await page.goto('https://demo.myshop.com/orders');
  await expect(page.getByText('Something went wrong loading your orders')).toBeVisible();
});

Testing error scenarios early helps you catch missing error messages, broken retry logic, or states where the UI silently gets stuck loading forever.

Common Mistakes #

Mistake 1 — Only testing happy-path network behaviour #

This leaves resilience untested.

❌ Wrong: Assuming backends will always respond quickly and successfully.

✅ Correct: Explicitly test how the UI reacts to slow, failing or partial responses.

Mistake 2 — Hard-coding unrealistic failure scenarios #

This reduces value.

❌ Wrong: Simulating errors that could never occur given the system design.

✅ Correct: Base failure scenarios on real outage reports or agreed risk models.