A contact form appears immediately, but its submit handler becomes ready only after application initialisation. A browser test finds the button and clicks before the page can process the action. Adding a two-second sleep appears to fix the test until a busy CI worker takes longer.
Reliable automation needs to synchronise with the behaviour the application exposes. Playwright supplies browser automation APIs, while Playwright Test provides a JavaScript and TypeScript test runner with fixtures, assertions, reporting, and execution controls. They help test real browser interactions without making arbitrary delays the primary synchronisation mechanism.
The result is evidence from particular scenarios, browsers, and environments. Playwright does not prove that every workflow is correct, isolate every backend dependency, or recognise every business rule. Its value comes from testing the parts of the application where browser behaviour matters.
Start With a User Outcome
Playwright’s getting-started documentation introduces the test runner and its browser workflow. Choose a small, consequential user journey before deciding how many pages or controls to automate. The expected outcome should be observable and linked to the requirement.
For a contact form, a useful scenario might enter an address, submit one request, and receive confirmation. Additional tests can examine validation failures, network errors, and duplicate submission. They should reflect the application’s intended behaviour rather than every possible implementation detail.
This illustrative test assumes a configured baseURL and an application exposing the stated labels, button, and status. It is a template for that application contract, not a test of this website:
import { test, expect } from '@playwright/test';
test('confirms a contact request', async ({ page }) => {
await page.goto('/contact');
await page.getByLabel('Email address').fill('reader@example.test');
await page.getByRole('button', {
name: 'Send request', exact: true,
}).click();
await expect(page.getByRole('status')).toHaveText('Request received');
});A confirmation message alone may not establish everything the requirement needs. If the application must create exactly one durable request, suitable backend or integration evidence should check that consequence too. A browser assertion can verify presentation without inspecting the whole transaction.
Wait for Relevant State Rather Than Elapsed Time
Playwright’s actionability checks examine conditions appropriate to the requested action. A click, for example, checks more than whether a matching element exists. These checks reduce timing assumptions around visible, enabled, stable, and interactable controls.
They do not establish application-specific readiness. A button can look actionable before its event handler is attached or before essential data is available. The application should expose meaningful readiness, such as keeping the action disabled until it can be handled, and the test should verify the intended resulting state.
Retrying assertions repeatedly check supported expectations until they succeed or reach their timeout. Awaiting a locator assertion allows the page to reach the expected state. Capturing text once and applying an ordinary immediate equality check does not provide the same retry behaviour.
Timeouts still bound the check. They should reflect the expected operation and leave useful failure evidence, rather than become a substitute for understanding it. A longer wait can conceal a slow application just as a short fixed sleep can create an unreliable test.
Use Locators That Describe the Intended Control
Locators describe how to find elements when an operation needs them. Roles, accessible names, labels, visible text, and suitable test identifiers can make that description clearer than a chain of DOM positions.
A locator for the Send request button expresses the intended action. A locator for the third button under several nested div elements can break after a layout refactor that leaves the user’s experience unchanged. Choose a stable relationship that belongs to the behaviour being tested.
Resolve ambiguity deliberately. A page can contain several Save buttons, so scope the locator to the relevant form or dialog. Taking the first match without examining the reason can make the test act on the wrong record while still passing.
Accessible locators can encourage a useful interface contract, but using them does not constitute a complete accessibility assessment. Keyboard behaviour, focus management, announcements, contrast, and other requirements need appropriate checks beyond locating one labelled button.
Isolate Browser State and Server State Separately
Browser contexts provide independent browser-session state. Playwright Test’s usual page fixture uses a context for the test, reducing interference through cookies and browser storage. This is different from reusing one session and hoping earlier tests cleaned up correctly.
The backend can still be shared. Two tests using the same account or database row can interfere even when their browser contexts are separate. Assign suitable test identities and data, and define cleanup or disposable fixtures for server-side effects.
Parallel execution makes those assumptions visible. A test that passes alone can fail when another worker changes its account balance, deletes its fixture, or consumes a limited resource. Diagnose the shared dependency before treating every intermittent failure as a browser timing problem.
Authentication setup also needs a defined scope. Reusing stored authenticated browser state can save work, but it does not create a fresh server account for every test or grant permission to modify real customer data. Keep credentials and environment targets appropriate to the test’s intended effects.
Decide Which Network Boundaries Are Real
Playwright can intercept and mock network traffic. A controlled response can make it practical to test empty data, errors, or a delayed result without depending on an unstable external service. It also narrows what the test demonstrates.
A mocked checkout response can verify how the interface presents success or failure. It does not prove that the real payment adapter or authorisation service accepts the request. Keep suitable contract or integration checks for those boundaries, rather than letting a browser test’s realistic appearance imply complete coverage.
Choose the boundary per scenario. A small number of critical journeys may use the real application stack in a controlled environment, while many interface states use deterministic responses. Record what is replaced so failures and successes can be interpreted accurately.
Service workers, caches, and application-specific request paths can affect what interception sees. Use the documented behaviour for the test setup, and verify the intended request was actually controlled. Do not infer successful mocking merely because the test completed quickly.
Run the Browser Matrix the Requirement Needs
Playwright supports Chromium, Firefox, and WebKit, with browser installation and version requirements tied to the tool release. Testing its WebKit build is not identical to testing every Safari release or every physical Apple device.
Device emulation can vary viewport and selected browser settings. It does not turn a desktop process into a complete physical-device environment. Include additional testing where hardware, operating-system behaviour, or an actual supported browser version is important to the product.
Choose a matrix based on the audience and failure risks. Running every scenario against every configuration can consume substantial CI time without adding equivalent evidence. A focused critical-flow matrix and cheaper checks elsewhere can provide a more maintainable strategy.
Keep Failure Evidence and Retries Honest
Trace Viewer can help examine recorded actions, page state, and network activity from a test. Screenshots, reports, and application logs add other evidence. Collect what is needed while accounting for sensitive test data and credentials in artefacts.
A Playwright execution trace is not the same thing as a distributed application trace. Correlating the test request with service tracing can help identify whether a failure arose in the interface, application, or dependency path.
Test retries can reveal intermittent behaviour and provide another observation. A pass on retry does not explain the first failure or make it harmless. Track unstable tests and investigate whether the cause is product behaviour, data interference, or an unreliable expectation.
Use Browser Evidence Where It Adds Something
Place calculations, state-machine rules, and many API contracts in appropriate lower-level checks. Use Playwright where rendering, browser state, navigation, interaction, and the complete user path provide information those checks cannot. The distinction between contract and integration testing helps define the supporting layers.
| Requirement | Useful evidence | What a browser-only check can miss |
|---|---|---|
| Form validation is understandable | Visible errors and focus behaviour | Server acceptance of a direct invalid request |
| Only authorised users may change a record | API permission checks plus the relevant user flow | A hidden button is not access enforcement |
| Submission survives a page refresh | Reloaded interface and durable server state | A temporary success message may exist only locally |
Choose the assertion boundary from the requirement, then combine the necessary evidence. A realistic browser interaction can be an important part of that evidence without being the only check the system needs.
A trusted suite has clear assertions, controlled state, meaningful failure evidence, and owners who repair unreliable checks. Playwright supplies useful mechanisms for that work. The confidence comes from the scenarios and boundaries the team has deliberately verified, rather than from the fact that a browser opened and a script reached its last line.
