Installations
npm install @playwright/test-runner
Developer Guide
Typescript
No
Module System
CommonJS
Min. Node Version
>=10.17.0
Node Version
12.13.1
NPM Version
6.12.1
Score
62.5
Supply Chain
83
Quality
78.9
Maintenance
100
Vulnerability
97.3
License
Releases
Unable to fetch releases
Contributors
Unable to fetch Contributors
Languages
TypeScript (98.69%)
JavaScript (1.31%)
validate.email 🚀
Verify real, reachable, and deliverable emails with instant MX records, SMTP checks, and disposable email detection.
Developer
Download Statistics
Total Downloads
72,354
Last Day
72
Last Week
259
Last Month
811
Last Year
7,299
GitHub Statistics
Apache-2.0 License
844 Stars
293 Commits
27 Forks
17 Watchers
2 Branches
10,000 Contributors
Updated on Feb 11, 2025
Bundle Size
354.32 kB
Minified
101.80 kB
Minified + Gzipped
Package Meta Information
Latest Version
0.9.24
Package Id
@playwright/test-runner@0.9.24
Size
58.58 kB
NPM Version
6.12.1
Node Version
12.13.1
Published on
Oct 10, 2020
Total Downloads
Cumulative downloads
Total Downloads
72,354
Last Day
80%
72
Compared to previous day
Last Week
121.4%
259
Compared to previous week
Last Month
-9.8%
811
Compared to previous month
Last Year
27.2%
7,299
Compared to previous year
Daily Downloads
Weekly Downloads
Monthly Downloads
Yearly Downloads
Dependencies
19
Content
Fixtures
Base concepts
Playwright test runner is based on the concept of the test fixtures. Test fixtures are used to establish environment for each test, giving the test everything it needs and nothing else. Here is how typical test environment setup differs between traditional BDD and the fixture-based one:
Without fixtures:
1describe('database', () => { 2 let database; 3 let table; 4 5 beforeAll(() => { 6 database = connect(); 7 }); 8 9 afterAll(() => { 10 database.dispose(); 11 }); 12 13 beforeEach(()=> { 14 table = database.createTable(); 15 }); 16 17 afterEach(()=> { 18 database.dropTable(table); 19 }); 20 21 it('create user', () => { 22 table.insert(); 23 // ... 24 }); 25 26 it('update user', () => { 27 table.insert(); 28 table.update(); 29 // ... 30 }); 31 32 it('delete user', () => { 33 table.insert(); 34 table.delete(); 35 // ... 36 }); 37});
With fixtures:
1import { fixtures } from '@playwright/test-runner'; 2 3const { it } = fixtures 4 .defineWorkerFixtures<{ database: Database }>({ 5 database: async ({}, runTest) => { 6 const db = connect(); 7 await runTest(db); 8 db.dispose(); 9 } 10 }) 11 .defineTestFixtures<{ table: Table }>({ 12 table: async ({}, runTest) => { 13 const t = database.createTable(); 14 await runTest(t); 15 database.dropTable(t); 16 } 17 }); 18 19it('create user', ({ table }) => { 20 table.insert(); 21 // ... 22}); 23 24it('update user', ({ table }) => { 25 table.insert(); 26 table.update(); 27 // ... 28}); 29 30it('delete user', ({ table }) => { 31 table.insert(); 32 table.delete(); 33 // ... 34});
You declare exact fixtures that the test needs and the runner initializes them for each test individually. Tests can use any combinations of the fixtures to tailor precise environment they need. You no longer need to wrap tests in describe
s that set up environment, everything is declarative and typed.
There are two types of fixtures: test
and worker
. Test fixtures are set up for each test and worker fixtures are set up for each process that runs test files.
Test fixtures
Test fixtures are set up for each test. Consider the following test file:
1// hello.spec.ts 2import { it, expect } from './hello.fixtures'; 3 4it('hello world', ({ hello, world }) => { 5 expect(`${hello}, ${world}!`).toBe('Hello, World!'); 6}); 7 8it('hello test', ({ hello, test }) => { 9 expect(`${hello}, ${test}!`).toBe('Hello, Test!'); 10});
It uses fixtures hello
, world
and test
that are set up by the framework for each test run.
Here is how test fixtures are declared and defined:
1// hello.fixtures.ts 2import { fixtures as baseFixtures } from '@playwright/test-runner'; 3export { expect } from '@playwright/test-runner'; 4 5// Define test fixtures |hello|, |world| and |test|. 6 7type TestFixtures = { 8 hello: string; 9 world: string; 10 test: string; 11}; 12 13const fixtures = baseFixtures.defineTestFixtures<TestFixtures>({ 14 hello: async ({}, runTest) => { 15 // Set up fixture. 16 const value = 'Hello'; 17 // Run the test with the fixture value. 18 await runTest(value); 19 // Clean up fixture. 20 }, 21 22 world: async ({}, runTest) => { 23 await runTest('World'); 24 }, 25 26 test: async ({}, runTest) => { 27 await runTest('Test'); 28 } 29}); 30export const it = fixtures.it;
Fixtures can use other fixtures.
1 ... 2 helloWorld: async ({hello, world}, runTest) => { 3 await runTest(`${hello}, ${world}!`); 4 } 5 ...
With fixtures, test organization becomes flexible - you can put tests that make sense next to each other based on what they test, not based on the environment they need.
Worker fixtures
Playwright test runner uses worker processes to run test files. You can specify the maximum number of workers using --workers
command line option. Similarly to how test fixtures are set up for individual test runs, worker fixtures are set up for each worker process. That's where you can set up services, run servers, etc. Playwright test runner will reuse the worker process for as many test files as it can, provided their worker fixtures match and hence environments are identical.
Here is how the test looks:
1// express.spec.ts 2import { it, expect } from './express.fixtures'; 3import fetch from 'node-fetch'; 4 5it('fetch 1', async ({ port }) => { 6 const result = await fetch(`http://localhost:${port}/1`); 7 expect(await result.text()).toBe('Hello World 1!'); 8}); 9 10it('fetch 2', async ({ port }) => { 11 const result = await fetch(`http://localhost:${port}/2`); 12 expect(await result.text()).toBe('Hello World 2!'); 13});
And here is how fixtures are declared and defined:
1// express.fixtures.ts 2import { fixtures as baseFixtures } from '@playwright/test-runner'; 3export { expect } from '@playwright/test-runner'; 4import express from 'express'; 5import type { Express } from 'express'; 6 7// Declare worker fixtures. 8type ExpressWorkerFixtures = { 9 port: number; 10 express: Express; 11}; 12const fixtures = baseFixtures.defineWorkerFixtures<ExpressWorkerFixtures>({ 13 // Define |port| fixture that has unique value value of the worker process index. 14 port: async ({ testWorkerIndex }, runTest) => { 15 await runTest(3000 + testWorkerIndex); 16 }, 17 18 // Define the express worker fixture, make it start automatically for every worker. 19 autoExpress: async ({ port }, runTest) => { 20 const app = express(); 21 app.get('/1', (req, res) => { 22 res.send('Hello World 1!') 23 }); 24 app.get('/2', (req, res) => { 25 res.send('Hello World 2!') 26 }); 27 let server; 28 console.log('Starting server...'); 29 await new Promise(f => { 30 server = app.listen(port, f); 31 }); 32 console.log('Server ready'); 33 await runTest(server); 34 console.log('Stopping server...'); 35 await new Promise(f => server.close(f)); 36 console.log('Server stopped'); 37 }, 38}); 39export const it = fixtures.it;
Parameters
It is common to run tests in different configurations, for example when running web app tests against multiple browsers or testing two different versions of api endpoint. Playwright test runner supports this via parameters - define the parameter and start using it in a test or a fixture.
Consider the following test that uses an API url endpoint:
1// api.spec.ts 2import { it, expect } from './api.fixtures'; 3import fetch from 'node-fetch'; 4 5it('fetch 1', async ({ apiUrl }) => { 6 const result = await fetch(`${apiUrl}/hello`); 7 expect(await result.text()).toBe('Hello'); 8});
Here is how to define the api version parameter:
1// api.fixtures.ts 2import { fixtures as baseFixtures } from '@playwright/test-runner'; 3export { expect } from '@playwright/test-runner'; 4 5const fixtures = baseFixtures 6 .defineParameter('version', 'API version', 'v1') 7 .defineWorkerFixtures<{ apiUrl: string }>({ 8 apiUrl: async ({ version }, runTest) => { 9 const server = await startServer(); 10 await runTest(`http://localhost/api/${version}`); 11 await server.close(); 12 } 13 }); 14export const it = fixtures.it;
In the command line
Given the example above, it is possible to run tests against the specific api version.
TODO: do not assume this is read top-bottom, each section should be self-contained
TODO: update the npx command.
1# Run against the default version (v1 in our case). 2npx test-runner tests 3# Run against the specified version. 4npx test-runner tests -p version=v2
Generating tests
TODO: do not assume this is read top-bottom, each section should be self-contained
It is also possible to run tests against multiple api versions.
1// api.fixtures.ts 2 3// Generate three versions of each test that directly or indirectly 4// depends on the |version| parameter. 5fixtures.generateParametrizedTests('version', ['v1', 'v2', 'v3']);
TODO: update the npx command.
1npx test-runner tests -p version=v1 -p version=v2

No vulnerabilities found.
Reason
no dangerous workflow patterns detected
Reason
security policy file detected
Details
- Info: security policy file detected: SECURITY.md:1
- Info: Found linked content: SECURITY.md:1
- Info: Found disclosure, vulnerability, and/or timelines in security policy: SECURITY.md:1
- Info: Found text in security policy: SECURITY.md:1
Reason
no binaries found in the repo
Reason
0 existing vulnerabilities detected
Reason
license file detected
Details
- Info: project has a license file: LICENSE:0
- Info: FSF or OSI recognized license: Apache License 2.0: LICENSE:0
Reason
Found 7/30 approved changesets -- score normalized to 2
Reason
project is archived
Details
- Warn: Repository is archived.
Reason
detected GitHub workflow tokens with excessive permissions
Details
- Warn: no topLevel permission defined: .github/workflows/main.yml:1
- Info: no jobLevel write permissions found
Reason
dependency not pinned by hash detected -- score normalized to 0
Details
- Warn: GitHub-owned GitHubAction not pinned by hash: .github/workflows/main.yml:14: update your workflow using https://app.stepsecurity.io/secureworkflow/microsoft/folio/main.yml/master?enable=pin
- Warn: GitHub-owned GitHubAction not pinned by hash: .github/workflows/main.yml:15: update your workflow using https://app.stepsecurity.io/secureworkflow/microsoft/folio/main.yml/master?enable=pin
- Warn: GitHub-owned GitHubAction not pinned by hash: .github/workflows/main.yml:34: update your workflow using https://app.stepsecurity.io/secureworkflow/microsoft/folio/main.yml/master?enable=pin
- Warn: GitHub-owned GitHubAction not pinned by hash: .github/workflows/main.yml:35: update your workflow using https://app.stepsecurity.io/secureworkflow/microsoft/folio/main.yml/master?enable=pin
- Warn: npmCommand not pinned by hash: .github/workflows/main.yml:42
- Warn: npmCommand not pinned by hash: .github/workflows/main.yml:22
- Info: 0 out of 4 GitHub-owned GitHubAction dependencies pinned
- Info: 0 out of 2 npmCommand dependencies pinned
Reason
no effort to earn an OpenSSF best practices badge detected
Reason
project is not fuzzed
Details
- Warn: no fuzzer integrations found
Reason
SAST tool is not run on all commits -- score normalized to 0
Details
- Warn: 0 commits out of 27 are checked with a SAST tool
Score
4.7
/10
Last Scanned on 2025-03-10
The Open Source Security Foundation is a cross-industry collaboration to improve the security of open source software (OSS). The Scorecard provides security health metrics for open source projects.
Learn MoreOther packages similar to @playwright/test-runner
@storybook/test-runner
Test runner for Storybook stories
@web/test-runner-playwright
Playwright browser launcher for Web Test Runner
playwright-test
Run mocha, zora, uvu, tape and benchmark.js scripts inside real browsers with playwright.
playwright-fluent
Fluent API around playwright