Checkpoint: The Reliability Loop in One Scenario
The first two mechanisms in Playwright become useful when they operate together. A semantic locator is not enough if a test inherits the wrong account, and a clean BrowserContext is not enough if the test clicks a moving or ambiguous element. This checkpoint connects interaction, state, external data, and evidence through one realistic flow so the reader can decide which control scope owns a failure rather than calling every failure “flakiness.”
A checkout flow as one controlled chain
Imagine an authenticated checkout page. The test must open the page, enter an address, wait for validation, place the order, and observe a confirmation. The product behavior is familiar, but the reliability question is layered: what must be true before the interaction, what must be true for the interaction, and what must be true after it?
The flow starts before navigation. The test receives a fresh BrowserContext and a page fixture. The context may load a prepared authentication state, but the test still has a defined browser-local starting point rather than whichever cookies a previous case left behind. If the scenario needs an account that can alter server-side orders, its account and order data must also be safe for this test or deliberately coordinated with other workers. The clean context is a necessary initial condition, not the whole environment.
The test then expresses intent through a locator. It finds the address field by its label and the Place order control by its role and accessible name, or by an explicit test contract when that is the better boundary. These choices do more than make the code readable. They identify the field and control that the user means, even if the application re-renders its form while validation is in progress. A locator remains a description to resolve at action time; it is not a claim that one DOM node will live forever.
The interaction passes through actionability. When the address is filled, the field must be visible, enabled, and editable. When the order button is clicked, Playwright waits for a unique, visible, stable, event-receiving, enabled element. If the button is disabled while the server validates the address, the wait follows the condition that matters. A fixed pause would only guess how long validation takes. If validation never succeeds, the timeout identifies a missing readiness condition instead of allowing the test to fail later at an unrelated assertion.
After the click, the test uses a web-first assertion to observe the confirmation state. It may wait for a confirmation heading, a meaningful order message, or a URL transition, depending on what the product promises. The assertion is not a duplicate of actionability. Actionability asks whether input can reach the intended control; the assertion asks whether the application produced the intended consequence. The two checks form a sequence, and each can fail for a different reason.