What a browser smoke suite is for
Unit tests tell you that pieces of code behave. A browser test tells you that a visitor can finish something: sign up, log in, pay in test mode. A small set of these on the few flows that earn money or lose customers is a smoke suite, and it fails loudly when a release breaks one. Playwright's own best-practices page sets the ground rules that keep such a suite useful. Make each test completely isolated, with its own storage, cookies and data. Use locators that describe what a user sees, such as a button's role and name, rather than CSS classes that change. Use assertions that wait for a condition instead of checking once. Only test what you control.
- Stub third-party services with page.route and route.fulfill, so the test never charges a card or sends an email.
- Assert an observable end state, not just that a page opened.
The usual failure patterns, and where to read about them
Most unreliable browser tests fail for one of three reasons. Timing: the test acted or asserted before the page was ready, and a fixed pause was added that fails on a slow day. Shared data: parallel tests used the same account or record. Environment: the test passes locally and fails in CI because of operating system, worker count, data or network differences. Each has its own guide, and each guide ends with how the matching paid job is accepted. Playwright waits for visible, stable, receives-events and enabled checks before an action, which is why most timing failures are really failures of one of those checks.
- Test fails when the page is slow: read the guide on waiting for a condition.
- Tests collide when run together: read the guide on accounts and parallel workers.
- Test fails only in CI: read the guide on collecting a trace first.
What a browser suite does not do
A smoke suite does not replace unit tests, measure speed or watch production. It checks a few flows against a staging or preview copy with synthetic accounts. It does not prove accessibility: Playwright's accessibility page says automated checks detect some common problems and that many problems need manual testing. It does not guarantee that a flow works for every browser, device or data condition, only for those you test. And a suite that is flaky is worse than no suite, because the team learns to ignore it; each test must pass repeated runs before it is relied on.
- Keep the suite small and fast enough to run on every pull request.
- Run it against non-production data only.
Ask for the right work
Three bounded jobs sit around Playwright. A browser smoke suite for three named flows, run on every pull request, is priced from a published test price of £995 and accepted by 20 consecutive passing runs and a deliberate break per flow. Stabilising up to five named flaky tests is quoted per test, from £395 for one test, after the tests and their runner are known. An accessibility audit report for one flow is £695 and lists barriers; it is not a conformance statement. Every price is an untested hypothesis, nothing is charged until scope and terms are agreed in writing, and we have not delivered these jobs for a client before. Send the flow names, whether a staging copy exists and which CI service runs your builds; do not send code, accounts or keys.
Sources and limits
- Playwright: best practices Checked 2026-10-11.
- Each test should be completely isolated with its own storage, cookies and data, and web-first assertions wait until the expected condition is met.
- Locators come with auto-waiting, user-facing attributes are preferred over CSS or XPath selectors, and third-party dependencies should be stubbed with page.route rather than tested.
- For CI the page recommends the trace viewer, running often and on Linux, and discourages recording a trace for every test.
- Playwright: actionability Checked 2026-10-11.
- Before an action Playwright waits for visible, stable, receives-events and enabled checks as relevant, and fails with a TimeoutError if they do not pass in time.
- Playwright: mocking APIs Checked 2026-10-11.
- page.route intercepts matching requests and route.fulfill supplies a response, so no request reaches the real API.
- Playwright: accessibility testing Checked 2026-10-11.
- Automated accessibility checks can detect some common problems, and many problems can only be found by manual testing.