Browser tests pass alone and collide when run together: give each test its own account and data

Know what runs at the same time

Playwright runs test files in parallel by default, in separate worker processes that cannot talk to each other. Tests inside one file run in order in the same worker. So two tests in different files can be signed in as the same user at the same moment, each changing that user's basket, profile or settings. Each test has its own browser storage, so the browser side is separate, but the server side is one shared system. A failure that appears only when the suite runs together, and disappears with a single worker, is a strong hint that tests are sharing data.

• Run the failing test alone, then with one worker, then with the usual workers, and compare. Setting one worker disables parallelism, which makes it a useful experiment even if it is not the fix.
• Note which tests use the same account, the same record or the same email address.

Isolate the data, not just the browser

The best-practices page asks for each test to be completely isolated, with its own storage, cookies and data. The authentication page makes the server-side half explicit: for tests that change shared server state, use one account per parallel worker, built with a worker-scoped fixture that picks an account by the worker's parallel index. The parallelism page shows the same idea for data: derive a user or record name from the worker index, and derive other identifiers and file paths from the test's own identifier, so two tests never write to the same thing. Create the data a test needs inside the test or its fixture, instead of relying on a record another test created.

• Give each worker its own test account, and create it for the run rather than borrowing a real customer's.
• Use unique names or numbers per test for records such as orders and emails.
• Create what a test needs at its start, and do not rely on leftovers from an earlier test.

Reuse a login without leaking it

Logging in at the start of every test is slow, so Playwright can log in once in a setup project and save the browser state for later tests to load. The saved file holds sensitive cookies and headers that could impersonate the account, and the documentation strongly discourages committing it to any repository, public or private. Keep it in an ignored folder, use a test account that exists only for this purpose, and delete the file when the session expires. A saved login also means every test starts with the same account, so it makes the shared-data problem worse unless you also use per-worker accounts.

• Add the folder that holds saved state to the ignore file before the first run.
• Never save the state of a real person's or an administrator's account.

Serial mode and one worker are workarounds, and how the paid job is accepted

Serial mode keeps dependent tests together and in order, and with retries enabled the whole group is retried together. The documentation says it is usually better to make tests isolated. Running everything on one worker also hides the collision at the price of a slower suite. For the browser smoke suite job, each test uses its own synthetic account and data, so the tests can run in any order, and acceptance requires 20 consecutive runs in the pull request job with retries disabled for the check. We run against a staging or preview copy only, with test accounts you create for the job. Send the flow names and whether staging exists; do not send passwords, real accounts or customer data.