How to Run Playwright Tests in Parallel Without Increasing Flakiness

Running Playwright tests in parallel can make a suite significantly faster, but parallel execution exposes tests that depend on shared users, shared data, execution order, or other shared state.

The key is simple: tests running in parallel must be independent. If two tests modify the same account, record, file, or application state, increasing parallelism can turn an otherwise stable test into a flaky one.

How do you run tests in parallel with Leapwork Play?

With Leapwork Play, parallel execution is configured at the RunList level. Play then runs multiple test cases simultaneously according to the configured parallel execution setting.

This gives you the Playwright test execution model while Play provides the workflow for grouping and running the test cases in parallel.

How do you run Playwright tests in parallel?

Playwright runs tests using worker processes. You can control the number of workers from the command line:

npx playwright test --workers=4

Or configure workers in your Playwright configuration:

import { defineConfig } from '@playwright/test';

export default defineConfig({
  workers: 4
});

But increasing the worker count is only safe when the tests do not interfere with each other.

For example, this can become flaky:

Test A → update Customer 100
Test B → delete Customer 100

Both tests may work independently but become unpredictable when they run at the same time.

A safer design is:

Test A → Customer A
Test B → Customer B

The objective is not simply more workers. It is more independent tests running concurrently.

How do you prevent parallel Playwright tests from becoming flaky?

Parallel execution usually exposes shared-state problems rather than creating them.

Check whether tests share:

The safest approach is to make each test responsible for the state it needs.

For example:

Parallel run

Test A → User A → Order A
Test B → User B → Order B
Test C → User C → Order C

rather than:

Test A ─┐
Test B ─┼→ Same User → Same Order
Test C ─┘

If a test only becomes flaky after enabling parallel execution, shared state should be one of the first things you investigate.

How Play extends Playwright parallel execution

Play complements Playwright by adding the RunList and managed execution workflow around parallel Playwright tests.

How to make a large Playwright suite faster

For a large suite, the biggest gains usually come from increasing safe concurrency rather than making individual tests faster.

Start by running independent tests in parallel and gradually increase the worker count:

npx playwright test --workers=4

Before increasing concurrency, make sure tests do not share mutable users, test data, files, or application state.

The goal is simple: run more independent tests at the same time without introducing flakiness.

What if a test passes alone but fails in parallel?

Treat that as useful evidence. Run the failing test without concurrency. For example:

npx playwright test tests/orders.spec.ts --workers=1

If it becomes reliable, investigate what changes when another test runs at the same time. Do not immediately make the entire suite serial. First determine which dependency prevents the test from running independently.

Best practices

• Use Play RunLists with Parallel execution when you want to group and run multiple Playwright test cases simultaneously through Play.

• Keep parallel tests independent.

• Give tests separate users or test data when they modify state.

• Do not depend on another test having run first.

• Avoid sharing mutable files or application records between parallel tests.

• Treat a test that fails only in parallel as a signal to investigate shared state.

• Increase concurrency gradually rather than assuming more parallel execution will always make the suite faster.

Troubleshooting

Frequently asked questions

How do I run Playwright tests in parallel?

Playwright uses worker processes for parallel execution. You can control the number of workers using configuration or --workers.

npx playwright test --workers=4

Why do Playwright tests become flaky when run in parallel?

Usually because tests share mutable state such as accounts, application records, files, sessions, or external dependencies.

How does Leapwork Play run Playwright tests in parallel?

Add multiple test cases to a RunList and configure its Execution mode as Parallel. Play then executes multiple test cases simultaneously according to the configured parallel execution setting.

Should I run every Playwright test in parallel?

Only when the tests can run independently. Tests that depend on shared mutable state or execution order should be redesigned or handled appropriately before increasing concurrency.

What should I do if a test passes with one worker but fails with several?

Investigate shared state and concurrency first. Running with one worker is useful for diagnosis, but permanently serializing the suite can hide the underlying test-isolation problem.