Writing Tests¶
So you’d like to write new tests for WPT? Great! For starters, we recommend reading the introduction to learn how the tests are organized and interpreted. You might already have an idea about what needs testing, but it’s okay if you don’t know where to begin. In either case, the guide on making a testing plan will help you decide what to write.
There’s also a load of general guidelines that apply to all tests.
Test Types¶
There are various different ways of writing tests:
JavaScript tests (testharness.js) are preferred for testing APIs and may be used for other features too. They are built with the testharness.js unit testing framework, and consist of assertions written in JavaScript. A high-level testharness.js tutorial is available.
Rendering tests should be used to verify that the browser graphically displays pages as expected. See the rendering test guidelines for tips on how to write great rendering tests. There are a few different ways to write rendering tests:
Reftests should be used to test rendering and layout. They consist of two or more pages with assertions as to whether they render identically or not. A high-level reftest tutorial is available. A print reftests variant is available too.
Visual tests should be used for checking rendering where there is a large number of conforming renderings such that reftests are impractical. They consist of a page that renders to final state at which point a screenshot can be taken and compared to an expected rendering for that user agent on that platform.
Crashtests tests are used to check that the browser is able to load a given document without crashing or experiencing other low-level issues (asserts, leaks, etc.). They pass if the load completes without error.
wdspec tests are written in Python using pytest and test the WebDriver browser automation protocol
Manual tests are used as a last resort for anything that can’t be tested using any of the above. They consist of a page that needs manual interaction or verification of the final result.
See file names for test types and features determined by the file names, and server features for advanced testing features.
Submitting Tests¶
Once you’ve written tests, please submit them using the typical GitHub Pull Request workflow; please make sure you run the lint script before opening a pull request!
Table of Contents¶
- General Test Guidelines
- Making a Testing Plan
- JavaScript Tests (testharness.js)
- testharness.js tutorial
- Rendering Test Guidelines
- Reftests
- Writing a reftest
- Print Reftests
- Visual Tests
- crashtest tests
- wdspec tests
- Manual Tests
- File Name Flags
- Server Features
- Submitting Tests
- Lint Tool
- The Ahem Font
- Test Assumptions
- CSS Metadata
- CSS User Stylesheets
- Writing H2 Tests
- testdriver.js Automation
- Testdriver extension tutorial
- Command-line utility scripts
- Test Templates
- Introduction to GitHub
- WebTransport in web-platform-tests