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.
- General Test Guidelines
- The Ahem Font
- Test Assumptions
- CSS Metadata
- CSS User Stylesheets
- File Name Flags
- Writing H2 Tests
- Lint Tool
- Making a Testing Plan
- Manual Tests
- Writing a reftest
- Rendering Test Guidelines
- Server Features
- Submitting Tests
- testdriver.js Automation
- Testdriver extension tutorial
- testharness.js Tests
- testharness.js tutorial
- Command-line utility scripts
- Visual Tests
- wdspec tests
- Test Templates
- Introduction to GitHub
Tests in this project use a few different approaches to verify expected behavior. The tests can be classified based on the way they express expectations:
- Rendering tests should be used to verify that the browser graphically
displays pages as expected. See the [rendering test guidelines][rendering]
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.
- 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.
- 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.
In general, there is a strong preference towards reftests and testharness.js tests types (as they can be easily run without human interaction), so they should be used in preference to the others even if it results in a somewhat cumbersome test; there is a far weaker preference between the two test types, and it is at times advisable to use testharness.js tests for things which would typically be tested using reftests but for which it would be overly cumbersome.