e2e-testing-patterns

Write Playwright tests by navigating to pages, interacting via role-based locators like getByRole and getByLabel, and asserting visible outcomes with expect. Organize page logic into Page Object classes and use fixtures to manage test data setup and cleanup.

Fix flaky tests by replacing fixed timeouts like waitForTimeout with condition-based waits such as waitForURL, waitForResponse, and auto-waiting assertions. Enable trace capture on first retry and use the trace viewer, screenshots, and videos to diagnose failures.

Use user-facing selectors: getByRole, getByLabel, and getByTestId with data-testid attributes. Avoid CSS classes, nth-child, and deep DOM paths, since they break when implementation details change.

Yes, Playwright mocks API responses using page.route to intercept requests and fulfill them with custom status codes and JSON bodies. You can also modify outgoing requests before continuing them, which is useful for testing error states and third-party services.

Yes, Playwright supports accessibility testing through the @axe-core/playwright integration. Run AxeBuilder against a page or scoped element and assert that the violations array is empty to catch accessibility regressions.

Avoid E2E tests for unit-level logic, API contract validation, and exhaustive edge cases, since they are slow and expensive. Follow the testing pyramid: many unit tests, fewer integration tests, and a small set of E2E tests covering critical user journeys.