Skip to main content


Parallelism In Playwright

Abstract Gravity Wave Background


Tests are executed in parallel with Playwright Test. It executes numerous parallel worker processes to do it. Test files are by default run in parallel. The same worker process executes each test in a single file sequentially.

  • Tests can be set up to run concurrently in a single file using test.describe.configure.
  • Using testProject.fullyParallel or testConfig.fullyparallel, you can set the entire project to execute all tests in parallel across all files.
  • Put a limit on the number of workers to one in order to disable parallelism.

For maximum efficiency, you can regulate the number of parallel worker processes and restrict the total number of test failures.

PlaywrightlogoNote: In this blog, we are using example tests created by playwright after installation.

Worker Processes

The test runner orchestrates worker processes, which are OS processes running independently, to execute each test. Each worker launches a new browser in an identical environment.

The workers are unable to communicate with one another. Multiple test files are typically executed in a single worker one after the other since Playwright Test reuses a single worker as much as it can to speed up testing.

To ensure a pristine environment for subsequent tests, workers are always shut down after a test failure.

Limit the Worker Processes

However, you can set a limit on the number of worker processes that can run in parallel via the command line or in the configuration file using the method described below.

From the Command Line

npx playwright test --workers 4


In the Configuration File

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

export default defineConfig({
  // Limit the number of workers on CI, use default locally
  workers: process.env.CI ? 2 : undefined,


Parallelize test in a single file

Playwright by default performs each test sequentially in a single file, although parallel testing is also an option. You can accomplish that in one of two ways: through the configuration file or the test.describe.configure().

The approach provided by the configuration file permits parallelism in each file of your test suite rather than the test.describe.configure() enables it in a single file.

By the way, this configuration’s setting is elementary; if you choose to enable it via the config file, the solution is as follows:

// playwright.config.js

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

module.exports = defineConfig({
  fullyParallel: true,

If you want to use test.describe.configure() to enable parallelism instead, the solution is this.

test.describe.configure({ mode: 'parallel' });

test('runs in parallel 1', async ({ page }) => { /* ... */ });
test('runs in parallel 2', async ({ page }) => { /* ... */ });


Spending some time discussing the beforeAll and afterAll hooks is crucial. The hooks will function similarly to beforeEach and afterEach hooks because they will run once for each process.

Note that concurrent tests cannot share any state or global variables because they run in separate worker processes. Every test runs every pertinent hook, including beforeAll and afterAll, only for itself.

Disable Parallelism

By permitting just one worker at any given point, you can disable all parallelism. Either set workers: –workers=1 on the command line or as workers: 1 in the configuration file.

npx playwright test --workers=1



In this article, you learned about what is Parallelism in Playwright, what is worker processes. How to disable parallelism, Parallelize test in a single file. I hope you enjoyed reading this post and found it to be useful.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Pravin Shivhare

Pravin Shivhare is an associate technical consultant at Perficient based out of Nagpur. He has over two years of experience in API automation testing. Pravin adores technology and is constantly eager to learn about new developments; he is a coder and blogger who enjoys traveling.

More from this Author

Follow Us