blob: e5739c9a6e60e32f2e83f6efad06449a3d9c1c26 (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
|
# Writing Tests
So you'd like to write new tests for WPT? Great! For starters, we recommend
reading [the introduction](../index) 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](making-a-testing-plan) will help you decide what to write.
There's also a load of [general guidelines](general-guidelines) that apply to all tests.
## Test Types
There are various different ways of writing tests:
* [JavaScript tests (testharness.js)](testharness) 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](testharness-tutorial)
is available.
* 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](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](reftest-tutorial) is available. A
[print reftests](print-reftests) variant is available too.
* [Visual tests](visual) 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](crashtest) 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](wdspec) tests are written in Python using
[pytest](https://docs.pytest.org/en/latest/) and test [the WebDriver browser
automation protocol](https://w3c.github.io/webdriver/)
* [Manual tests](manual) 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](file-names) for test types and features determined by the file names,
and [server features](server-features) for advanced testing features.
## Submitting Tests
Once you've written tests, please submit them using
the [typical GitHub Pull Request workflow](submission-process); please
make sure you run the [`lint` script](lint-tool) before opening a pull request!
## Table of Contents
```eval_rst
.. toctree::
:maxdepth: 1
general-guidelines
making-a-testing-plan
testharness
testharness-tutorial
rendering
reftests
reftest-tutorial
print-reftests
visual
crashtest
wdspec
manual
file-names
server-features
submission-process
lint-tool
ahem
assumptions
css-metadata
css-user-styles
h2tests
testdriver
testdriver-extension-tutorial
tools
test-templates
github-intro
../tools/webtransport/README.md
```
|
