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

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

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/pstfIpHDri4cG_2g7N2eRYrw

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

Thread query: playwright test.describe.serial vs fully parallel: when to use

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.