git clone https://github.com/microsoft/playwright
cd playwright
npm install
npm run build
npm test
All submissions, including submissions by project members, require review. We use GitHub pull requests for this purpose. Consult GitHub Help for more information on using pull requests.
To run code linter, use:
npm run eslint
When authoring new API methods, consider the following:
page.keyboard
and page.coverage
Commit messages should follow the Semantic Commit Messages format:
label(namespace): title
description
footer
fix
- playwright bug fixes.feat
- playwright features.docs
- changes to docs, e.g. docs(api.md): ..
to change documentation.test
- changes to playwright tests infrastructure.devops
- build-related work, e.g. CI related patches and general changes to the browser build infrastructurechore
- everything that doesn't fall under previous categoriesExample:
fix(firefox): make sure session cookies work
This patch fixes session cookies in firefox browser.
Fixes #123, fixes #234
All API classes, methods and events should have description in docs/src
. There's a documentation linter which makes sure documentation is aligned with the codebase.
To run the documentation linter, use:
npm run doc
For all dependencies (both installation and development):
A barrier for introducing new installation dependencies is especially high:
Playwright tests are located in test
and use Folio test runner.
These are integration tests, making sure public API methods and events work as expected.
npm run test
npm run ctest # also `ftest` for firefox and `wtest` for WebKit
it
with it.only
:...
// Using "it.only" to run a specific test
it.only('should work', async ({server, page}) => {
const response = await page.goto(server.EMPTY_PAGE);
expect(response.ok).toBe(true);
});
it
with it.skip
:...
// Using "it.skip" to skip a specific test
it.skip('should work', async ({server, page}) => {
const response = await page.goto(server.EMPTY_PAGE);
expect(response.ok).toBe(true);
});
HEADFUL=1 npm run ctest
CRPATH
, WKPATH
or FFPATH
env variable that points to browser executable:CRPATH=<path-to-executable> npm run ctest
HEADFUL=1 SLOW_MO=500 npm run wtest
When should a test be marked with skip
or fail
?
skip(condition)
: This test should never work for condition
where condition
is usually a certain browser like FFOX
(for Firefox),
WEBKIT
(for WebKit), and CHROMIUM
(for Chromium).
For example, the alt-click downloads test is marked
with skip(FFOX)
since an alt-click in Firefox will not produce a download
even if a person was driving the browser.
fail(condition)
: This test should eventually work for condition
where condition
is usually a certain browser like FFOX
(for Firefox),
WEBKIT
(for WebKit), and CHROMIUM
(for Chromium).
For example, the alt-click downloads test is marked
with fail(CHROMIUM || WEBKIT)
since Playwright performing these actions
currently diverges from what a user would experience driving a Chromium or
WebKit.
This project welcomes contributions and suggestions. Most contributions require you to agree to a Contributor License Agreement (CLA) declaring that you have the right to, and actually do, grant us the rights to use your contribution. For details, visit https://cla.opensource.microsoft.com.
When you submit a pull request, a CLA bot will automatically determine whether you need to provide a CLA and decorate the PR appropriately (e.g., status check, comment). Simply follow the instructions provided by the bot. You will only need to do this once across all repos using our CLA.
This project has adopted the Microsoft Open Source Code of Conduct. For more information see the Code of Conduct FAQ or contact opencode@microsoft.com with any additional questions or comments.