mirror of
https://github.com/servo/servo.git
synced 2025-08-07 14:35:33 +01:00
Update web-platform-tests to revision 9f01716569ae5dfd79675ea55718e48017d077a8
This commit is contained in:
WPT Sync Bot
parent
9b24798390
commit
93a31731d9
117 changed files with 3664 additions and 843 deletions
|
|
@ -22,9 +22,8 @@ the [general test guidelines](../writing-tests/general-guidelines).
|
|||
The review must happen in public, but there is no requirement for it
|
||||
to happen in any specific location. In particular if a vendor is
|
||||
submitting tests that have already been publicly reviewed in their own
|
||||
review system, that review may be carried forward. For other tests, we
|
||||
strongly recommend using either Reviewable or GitHub's built-in review
|
||||
tools.
|
||||
review system, that review may be carried forward. For other submissions, we
|
||||
recommend using GitHub's built-in review tools.
|
||||
|
||||
Regardless of what review tool is used, the review must be clearly
|
||||
linked in the pull request.
|
||||
|
|
@ -38,3 +37,26 @@ working on other things as tests frequently only get pushed upstream
|
|||
once the code lands in their implementation.
|
||||
|
||||
To assist with test reviews, a [review checklist](checklist) is available.
|
||||
|
||||
[GitHub.com allows reviewers to formally signal their approval of a pull
|
||||
request through a dedicated user
|
||||
interface.](https://help.github.com/en/articles/about-pull-request-reviews)
|
||||
Every pull request submitted to WPT must be approved by at least one project
|
||||
collaborator before it can be merged.
|
||||
|
||||
## Notifications
|
||||
|
||||
META.yml files are used only to indicate who should be notified of pull
|
||||
requests. If you are interested in receiving notifications of proposed
|
||||
changes to tests in a given directory, feel free to add yourself to the
|
||||
META.yml file.
|
||||
|
||||
## Finding contributions to review
|
||||
|
||||
Here are a few search filters to find things to review:
|
||||
|
||||
* [Open PRs (excluding vendor exports)](https://github.com/web-platform-tests/wpt/pulls?utf8=%E2%9C%93&q=is%3Apr+is%3Aopen+-label%3A%22mozilla%3Agecko-sync%22+-label%3A%22chromium-export%22+-label%3A%22webkit-export%22+-label%3A%22servo-export%22+-label%3Avendor-imports)
|
||||
* [Reviewed but still open PRs (excluding vendor exports)](https://github.com/web-platform-tests/wpt/pulls?utf8=%E2%9C%93&q=is%3Apr+is%3Aopen+-label%3Amozilla%3Agecko-sync+-label%3Achromium-export+-label%3Awebkit-export+-label%3Aservo-export+-label%3Avendor-imports+review%3Aapproved+-label%3A%22do+not+merge+yet%22+-label%3A%22status%3Aneeds-spec-decision%22) (Merge? Something left to fix? Ping other reviewer?)
|
||||
* [Open PRs without reviewers](https://github.com/web-platform-tests/wpt/pulls?q=is%3Apr+is%3Aopen+label%3Astatus%3Aneeds-reviewers)
|
||||
* [Open PRs with label `infra` (excluding vendor exports)](https://github.com/web-platform-tests/wpt/pulls?utf8=%E2%9C%93&q=is%3Apr+is%3Aopen+label%3Ainfra+-label%3A%22mozilla%3Agecko-sync%22+-label%3A%22chromium-export%22+-label%3A%22webkit-export%22+-label%3A%22servo-export%22+-label%3Avendor-imports)
|
||||
* [Open PRs with label `docs` (excluding vendor exports)](https://github.com/web-platform-tests/wpt/pulls?utf8=%E2%9C%93&q=is%3Apr+is%3Aopen+label%3Adocs+-label%3A%22mozilla%3Agecko-sync%22+-label%3A%22chromium-export%22+-label%3A%22webkit-export%22+-label%3A%22servo-export%22+-label%3Avendor-imports)
|
||||
|
|
|
|||
|
|
@ -10,15 +10,15 @@ and should be easy to run in any browser.
|
|||
|
||||
## Test Layout
|
||||
|
||||
Each top level directory in the repository corresponds to tests for a
|
||||
single specification, with the exception of `css/` which contains
|
||||
test suites for CSS WG specifications. For W3C specs, these directories
|
||||
are typically named after the shortname of the spec (i.e. the name
|
||||
used for snapshot publications under `/TR/`); for WHATWG specs, they
|
||||
are typically named after the subdomain of the spec (i.e. trimming
|
||||
`.spec.whatwg.org` from the URL); for other specs, something deemed
|
||||
sensible is used. In any case, there are occasional exceptions for
|
||||
historic reasons.
|
||||
Most of the repository's top-level directories hold tests for specific web
|
||||
standards. For [W3C specs](https://www.w3.org/standards/), these directories
|
||||
are typically named after the shortname of the spec (i.e. the name used for
|
||||
snapshot publications under `/TR/`); for [WHATWG
|
||||
specs](https://spec.whatwg.org/), they are typically named after the subdomain
|
||||
of the spec (i.e. trimming `.spec.whatwg.org` from the URL); for other specs,
|
||||
something deemed sensible is used. The `css/` directory contains test suites
|
||||
for [the CSS Working Group
|
||||
specifications](https://www.w3.org/Style/CSS/current-work).
|
||||
|
||||
Within the specification-specific directory there are two common ways
|
||||
of laying out tests: the first is a flat structure which is sometimes
|
||||
|
|
@ -28,6 +28,12 @@ in the specification. The latter provides some implicit metadata about
|
|||
the part of a specification being tested according to its location in
|
||||
the filesystem, and is preferred for larger specifications.
|
||||
|
||||
For example, tests in HTML for ["The History
|
||||
interface"](https://html.spec.whatwg.org/multipage/history.html#the-history-interface)
|
||||
are located in `html/browsers/history/the-history-interface/`.
|
||||
|
||||
Various resources that tests depend on are in `common`, `images`, `fonts`,
|
||||
`media`, and `resources`.
|
||||
|
||||
## Test Types
|
||||
|
||||
|
|
|
|||
|
|
@ -249,7 +249,8 @@ GitHub UI. Below is one method and others can be found on
|
|||
4. Wait for feedback on your pull request and once your pull request is
|
||||
accepted, delete your branch (see '[When Pull Request is Accepted](#cleanup)').
|
||||
|
||||
That's it! Your pull request will go into a queue and will be reviewed soon.
|
||||
[This page on the submissions process](submission-process) has more detail
|
||||
about what to expect when contributing code to WPT.
|
||||
|
||||
## Refine
|
||||
|
||||
|
|
|
|||
|
|
@ -1,28 +1,24 @@
|
|||
# Submitting Tests
|
||||
|
||||
Test submission is via the typical [GitHub workflow][github flow]:
|
||||
Test submission is via the typical [GitHub workflow][github flow]. For detailed
|
||||
guidelines on setup and each of these steps, please refer to the [Github Test
|
||||
Submission](github-intro) documentation.
|
||||
|
||||
* Fork the [GitHub repository][repo] (and make sure you're still relatively in
|
||||
sync with it if you forked a while ago)
|
||||
* Fork the [GitHub repository][repo].
|
||||
|
||||
* Create a branch for your changes. Being a key of effective Git flow, it is
|
||||
strongly recommended that the **topic branch** tradition be followed here,
|
||||
i.e. the branch naming convention is based on the "topic" you will be working
|
||||
on, e.g. `git checkout -b topic-name`
|
||||
* Create a feature branch for your changes.
|
||||
|
||||
* Make your changes
|
||||
* Make your changes.
|
||||
|
||||
* Run the `lint` script in the root of your checkout to detect common
|
||||
mistakes in test submissions. This will also be run after submission
|
||||
and any errors will prevent your PR being accepted. If it detects an
|
||||
error that forms an essential part of your test, edit the list of
|
||||
exceptions stored in `tools/lint/lint.whitelist`.
|
||||
mistakes in test submissions. There is [detailed documentation for the lint
|
||||
tool](lint-tool).
|
||||
|
||||
* Commit your changes.
|
||||
|
||||
* Push your local branch to your GitHub repository.
|
||||
|
||||
* Using the GitHub UI create a Pull Request for your branch.
|
||||
* Using the GitHub UI, create a Pull Request for your branch.
|
||||
|
||||
* When you get review comments, make more commits to your branch to
|
||||
address the comments.
|
||||
|
|
@ -30,8 +26,9 @@ on, e.g. `git checkout -b topic-name`
|
|||
* Once everything is reviewed and all issues are addressed, your pull
|
||||
request will be automatically merged.
|
||||
|
||||
For detailed guidelines on setup and each of these steps, please refer to the
|
||||
[Github Test Submission](../writing-tests/github-intro) documentation.
|
||||
We can sometimes take a little while to go through pull requests because we
|
||||
have to go through all the tests and ensure that they match the specification
|
||||
correctly. But we look at all of them, and take everything that we can.
|
||||
|
||||
Hop on to the [mailing list][public-test-infra] or [IRC][]
|
||||
([webclient][web irc], join channel `#testing`) if you have an issue. There is
|
||||
|
|
|
|||
|
|
@ -297,6 +297,11 @@ only takes `actual` and `description` as arguments.
|
|||
The description parameter is used to present more useful error messages when
|
||||
a test fails.
|
||||
|
||||
When assertions are violated, they throw a runtime exception. This interrupts
|
||||
test execution, so subsequent statements are not evaluated. A given test can
|
||||
only fail due to one such violation, so if you would like to assert multiple
|
||||
behaviors independently, you should use multiple tests.
|
||||
|
||||
NOTE: All asserts must be located in a `test()` or a step of an
|
||||
`async_test()`, unless the test is a single page test. Asserts outside
|
||||
these places won't be detected correctly by the harness and may cause
|
||||
|
|
@ -802,6 +807,24 @@ asserts that one `assert_func(actual, expected_array_N, extra_arg1, ..., extra_a
|
|||
allows multiple behaviours. Test authors should not use this method simply to hide
|
||||
UA bugs.
|
||||
|
||||
## Formatting ##
|
||||
|
||||
When many JavaScript Object values are coerced to a String, the resulting value
|
||||
will be `"[object Object]"`. This obscures helpful information, making the
|
||||
coerced value unsuitable for use in assertion messages, test names, and
|
||||
debugging statements.
|
||||
|
||||
testharness.js provides a global function named `format_value` which produces
|
||||
more distinctive string representations of many kinds of objects, including
|
||||
arrays and the more important DOM Node types. It also translates String values
|
||||
containing control characters to include human-readable representations.
|
||||
|
||||
```js
|
||||
format_value(document); // "Document node with 2 children"
|
||||
format_value("foo\uffffbar"); // "\"foo\\uffffbar\""
|
||||
format_value([-0, Infinity]); // "[-0, Infinity]"
|
||||
```
|
||||
|
||||
## Metadata ##
|
||||
|
||||
It is possible to add optional metadata to tests; this can be done in
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue