- Clone this repository
git clone https://github.com/microsoft/playwright
cd playwright
- Install dependencies
npm install
- Build Playwright
npm run build
- Run all Playwright tests locally. For more information about tests, read Running & Writing Tests.
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.
- Coding style is fully defined in .eslintrc
- Comments should be generally avoided. If the code would not be understood without comments, consider re-writing the code to make it self-explanatory.
To run code linter, use:
npm run eslint
When authoring new API methods, consider the following:
- Expose as little information as needed. When in doubt, don’t expose new information.
- Methods are used in favor of getters/setters.
- The only exception is namespaces, e.g.
page.keyboard
andpage.coverage
- The only exception is namespaces, e.g.
- All string literals must be small case. This includes event names and option values.
- Avoid adding "sugar" API (API that is trivially implementable in user-space) unless they're very common.
Commit messages should follow the Semantic Commit Messages format:
label(namespace): title
description
footer
- label is one of the following:
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 categories
- namespace is put in parenthesis after label and is optional. Must be lowercase.
- title is a brief summary of changes.
- description is optional, new-line separated from title and is in present tense.
- footer is optional, new-line separated from description and contains "fixes" / "references" attribution to github issues.
Example:
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):
- Do not add a dependency if the desired functionality is easily implementable.
- If adding a dependency, it should be well-maintained and trustworthy.
A barrier for introducing new installation dependencies is especially high:
- Do not add installation dependency unless it's critical to project success.
- Every feature should be accompanied by a test.
- Every public api event/method should be accompanied by a test.
- Tests should be hermetic. Tests should not depend on external services.
- Tests should work on all three platforms: Mac, Linux and Win. This is especially important for screenshot tests.
Playwright tests are located in tests
and use @playwright/test
test runner.
These are integration tests, making sure public API methods and events work as expected.
- To run all tests:
npm run test
- To run all tests in Chromium
npm run ctest # also `ftest` for firefox and `wtest` for WebKit
- To run a specific test, substitute
it
withit.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);
});
- To disable a specific test, substitute
it
withit.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);
});
- To run tests in non-headless (headed) mode:
HEADFUL=1 npm run ctest
- To run tests with custom browser executable, specify
CRPATH
,WKPATH
orFFPATH
env variable that points to browser executable:
CRPATH=<path-to-executable> npm run ctest
- To run tests in slow-mode:
HEADFUL=1 SLOW_MO=500 npm run wtest
-
When should a test be marked with
skip
orfail
?-
skip(condition)
: This test should never work forcondition
wherecondition
is usually a certain browser likeFFOX
(for Firefox),WEBKIT
(for WebKit), andCHROMIUM
(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 forcondition
wherecondition
is usually a certain browser likeFFOX
(for Firefox),WEBKIT
(for WebKit), andCHROMIUM
(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 [email protected] with any additional questions or comments.