Update web-platform-tests to revision 58eb04cecbbec2e18531ab440225e38944a9c444

This commit is contained in:
Josh Matthews 2017-04-17 12:06:02 +10:00 committed by Anthony Ramine
parent 25e8bf69e6
commit 665817d2a6
35333 changed files with 1818077 additions and 16036 deletions

View file

@ -1,5 +1,4 @@
@sideshowbarker
@dontcallmedom
@zcorpan
@Ms2ger
@gsnedders

View file

@ -46,25 +46,17 @@ If you are a first-time GitHub user, read on for more details of the workflow.
## Test Repositories
The test repository that you contribute to will depend on the specification
that you are testing. Currently there are two test repositories, one for CSS
specification tests and the main W3C repository that contains tests for all
other specifications:
that you are testing.
**Main W3C test repository**: [github.com/w3c/web-platform-tests][main-repo]
**CSS specification test repository**: [github.com/w3c/csswg-test][css-repo]
## Fork
Now that you have Git set up, you will need to fork the test repository. This
will enable you to [submit][submit] your tests using a pull request (more on this
[below][submit]).
1. In the browser, go the the GitHub page for the test repository:
CSS test repository: [github.com/w3c/csswg-test][css-repo]
Main W3C test repository: [github.com/w3c/web-platform-tests][main-repo]
1. In the browser, go to [web-platform-tests on GitHub][main-repo].
2. Click the ![fork][forkbtn] button in the upper right.
@ -82,16 +74,9 @@ If your [fork](#fork) was successful, the next step is to clone (download a copy
### Clone the test repo
At the command prompt, cd into the directory where you want to keep the tests.
* If you forked the W3C Web Platform tests:
$ git clone --recursive https://github.com/username/web-platform-tests.git
If you forked the CSS tests:
$ git clone --recursive https://github.com/username/csswg-test.git
_This will download the tests into a directory named for the repo:_
`./web-platform-tests` _or_ `./csswg-test`.
_This will download the tests into a directory named for the repo:_ `web-platform-tests/`.
* You should now have a full copy of the test repository on your local
machine. Feel free to browse the directories on your hard drive. You can also
@ -104,7 +89,7 @@ At the command prompt, cd into the directory where you want to keep the tests.
* If you cloned the the test repo and did not use the `--recursive` option, you will likely have an empty `resources` directory at the root of your cloned repo. You can clone the submodules with these additional steps:
$ cd test-repo-root
$ cd web-platform-tests
$ git submodule update --init --recursive
_You should now see the submodules in the repository. For example,_ `testharness` _files in should be in the resources directory._
@ -124,16 +109,10 @@ repository.
$ git checkout master
3. Next, add the remote of the repository your forked. This assigns the
original repository to a remote called "upstream"
If you forked the [Web Platform Tests repository][main-repo]:
original repository to a remote called "upstream":
$ git remote add upstream https://github.com/w3c/web-platform-tests.git
If you forked the [CSSWG-test repository][css-repo]:
$ git remote add upstream https://github.com/w3c/csswg-test.git
4. To pull in changes in the original repository that are not present in your
local repository first fetch them:
@ -344,8 +323,8 @@ If it is possible to review the tests without a local copy,
but the reviewer still wants to make some simple tweaks to the tests before merging,
it is possible to do so via the Github web UI.
1. Open the pull request. E.g. https://github.com/w3c/csswg-test/pull/1234
2. Go to the ![Files changed][files-changed] view (e.g. https://github.com/w3c/csswg-test/pull/1234/files)
1. Open the pull request. E.g. https://github.com/w3c/web-platform-tests/pull/1234
2. Go to the ![Files changed][files-changed] view (e.g. https://github.com/w3c/web-platform-tests/pull/1234/files)
3. Locate the files you wish to change, and click the ![pencil][pencil-icon] icon in the upper right corner
4. Make the desired change
5. Write a commit message (including a good title) at the bottom
@ -406,7 +385,6 @@ you may also discard your connection to their repo:
[branch]: #branch
[commit]: #commit
[clone]: #clone
[css-repo]: https://github.com/w3c/csswg-test
[forkbtn]: {{ site.baseurl }}{% link /assets/forkbtn.png %}
[git]: https://git-scm.com/downloads
[git-book]: https://git-scm.com/book

View file

@ -166,7 +166,7 @@ see the [lint-tool documentation][lint-tool].
## CSS-Specific Requirements
In order to be included in an official specification testsuite, tests
for csswg-test have some additional requirements for:
for CSS have some additional requirements for:
* [Metadata][css-metadata], and
* [User style sheets][css-user-styles].

View file

@ -47,7 +47,7 @@ however.
## Submitting Tests
Once you're written tests, please submit them using
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!

View file

@ -22,9 +22,19 @@ all test types.
## Auto-generated test boilerplate
While most JavaScript tests require a certain amount of HTML
boilerplate to include the test library, etc., tests for Web Workers
can be written as JavaScript files which then have all the needed HTML
and setup script auto-generated.
boilerplate to include the test library, etc., tests which are
expressible purely in script (e.g. tests for workers) can have all the
needed HTML and script boilerplate auto-generated.
### Standalone window tests
Tests that only require a script file running in window scope can use
standalone window tests. In this case the test is a javascript file
with the extension `.window.js`. This is sourced from a generated
document which sources `testharness.js`, `testharnessreport.js` and
the test script. For a source script with the name
`example.window.js`, the corresponding test resource will be
`example.window.html`.
### Standalone workers tests
@ -55,7 +65,7 @@ worker scope.
In this case, the test is a JavaScript file with extension `.any.js`.
The test can then use all the usual APIs, and can be run from the path to the
JavaScript file with the `.js` replaced by `.worker.js` or `.html`.
JavaScript file with the `.js` replaced by `.worker.html` or `.html`.
For example, one could write a test for the `Blob` constructor by
creating a `FileAPI/Blob-constructor.any.js` as follows:
@ -67,9 +77,22 @@ creating a `FileAPI/Blob-constructor.any.js` as follows:
assert_false(blob.isClosed);
}, "The Blob constructor.");
This test could then be run from `FileAPI/Blob-constructor.any.worker.js` as well
This test could then be run from `FileAPI/Blob-constructor.any.worker.html` as well
as `FileAPI/Blob-constructor.any.html`.
### Including other JavaScript resources in auto-generated boilerplate tests
Use `// META: script=link/to/resource.js` at the beginning of the resource. For example,
// META: script=/common/utils.js
// META: script=resources/utils.js
can be used to include both the global and a local `utils.js` in a test.
### Specifying a timeout of long in auto-generated boilerplate tests
Use `// META: timeout=long` at the beginning of the resource.
[general guidelines]: {{ site.baseurl }}{% link _writing-tests/general-guidelines.md %}
[testharness-api]: {{ site.baseurl }}{% link _writing-tests/testharness-api.html %}

View file

@ -82,6 +82,7 @@ nav.home {
}
svg {
color: black;
width: auto;
height: $spacing-unit * 2;
}

View file

@ -5,16 +5,10 @@ title: Introduction
web-platform-tests is a W3C-coordinated effort to build a
cross-browser testsuite for the majority of
the [web platform][web-platform]; it excludes only CSS (whose
testsuite lives in [csswg-test][csswg-test]), ECMAScript (whose
testsuite lives in [test262][test262]), and WebGL (whose testsuite
the [web platform][web-platform]; it excludes only ECMAScript (whose
testsuite lives in [test262][test262]) and WebGL (whose testsuite
lives in [WebGL][WebGL]).
That said, csswg-test follows a superset of the policies of
web-platform-tests, so the documentation provided here should
similarly apply to it. Where extra policies apply, they are provided
in separate documents and linked from the appropriate section.
## Help!
If you get stuck or want clarification about anything, feel free to
@ -63,7 +57,7 @@ The testsuite has a few types of tests, outlined below:
* [Reftests][], which render two (or more) web
pages and combine them with equality assertions about their
rendering (e.g., A.html and B.html must render identically), run
rendering (e.g., `A.html` and `B.html` must render identically), run
either by the user switching between tabs/windows and trying to
observe differences or through automated scripts.
@ -193,7 +187,6 @@ partition from there to launch wptserve.
[web-platform]: https://platform.html5.org
[test262]: https://github.com/tc39/test262
[csswg-test]: https://github.com/w3c/csswg-test
[webgl]: https://github.com/KhronosGroup/WebGL
[public-test-infra]: https://lists.w3.org/Archives/Public/public-test-infra/
[IRC]: irc://irc.w3.org:6667/testing