## TL;DR

Use serial for tests that share mutable state like one database or one logged-in session, and fully parallel for independent UI tests. Keep serial blocks small; a whole file in serial mode is usually a sign the setup needs work.

## The query

```text
playwright test.describe.serial vs fully parallel: when to use
```

## Use this when

- parallel tests collide on shared data
- one spec needs ordered steps
- choosing an execution mode for a new file

## Not for

- how many workers to run
- sharding across machines
- retry configuration

## Steps

1. List what the tests share: database, files, global config, or a single user account. Expected output: a concrete inventory of shared mutable state.
2. Wrap only the state-sharing tests in test.describe.serial, leaving the rest parallel. Expected output: a small serial block inside a parallel file.
3. For parallel tests, give each test its own data (unique users, unique records) so they cannot collide. Expected output: no shared identifiers between parallel tests.
4. Measure the runtime of both modes on the file. Expected output: timing numbers for serial vs parallel.
5. If the serial block keeps growing, invest in per-test isolation so it can go parallel again. Expected output: a shrinking serial block over time.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_fIpHD_ri4cG_2g7N2eRYrw