Mirrors/servo
1
0
Fork 0
mirror of https://github.com/servo/servo.git synced 2025-08-15 10:25:32 +01:00
Code Issues Projects Releases Packages Wiki Activity

Update web-platform-tests to revision 3b3585e368841b77caea8576fa56cef91c3fbdf0

Browse source
This commit is contained in:
Ms2ger 2016-09-26 10:52:50 +02:00
parent d00639c55f
commit 3b4f0ec0bb
541 changed files with 14609 additions and 3288 deletions
Download patch file Download diff file Expand all files Collapse all files

41
tests/wpt/web-platform-tests/docs/configuration.md
View file

@ -18,12 +18,13 @@ your
following entries are required:
```
127.0.0.1 web-platform.test
127.0.0.1 www.web-platform.test
127.0.0.1 www1.web-platform.test
127.0.0.1 www2.web-platform.test
127.0.0.1 xn--n8j6ds53lwwkrqhv28a.web-platform.test
127.0.0.1 xn--lve-6lad.web-platform.test
127.0.0.1 web-platform.test
127.0.0.1 www.web-platform.test
127.0.0.1 www1.web-platform.test
127.0.0.1 www2.web-platform.test
127.0.0.1 xn--n8j6ds53lwwkrqhv28a.web-platform.test
127.0.0.1 xn--lve-6lad.web-platform.test
0.0.0.0 nonexistent-origin.web-platform.test
```
## Cloning the Repository
@ -39,11 +40,11 @@ update all submodules:
## Font Files
Many layout tests require a set of test-specific fonts, notably
Ahem. These are available from the
[CSS Fonts](http://www.w3.org/Style/CSS/Test/Fonts/) website. These
must be installed according to the normal font-install procedure for
your operating system.
A number of tests rely upon a set of custom fonts, with
[Ahem](https://github.com/w3c/csswg-test/raw/master/fonts/ahem/ahem.ttf)
being required to be installed according to the normal font-install
procedure for your operating system. Other tests which require other
fonts explicitly state this and provide links to required fonts.
## Running the Test Server
@ -76,3 +77,21 @@ like:
```
"ssl": {"openssl": {"binary": "/path/to/openssl"}}
```
### Windows Notes
Running wptserve with SSL enabled on Windows typically requires
installing an OpenSSL distribution.
[Shining Light](https://slproweb.com/products/Win32OpenSSL.html)
provide a convenient installer that is known to work, but requires a
little extra setup.
After installation ensure that the path to OpenSSL is on your `%Path%`
environment variable.
Then set the path to the default OpenSSL configuration file (usually
something like `C:\OpenSSL-Win32\bin\openssl.cfg` in the server
configuration. To do this copy `config.default.json` in the
web-platform-tests root to `config.json`. Then edit the JSON so that
the key `ssl/openssl/base_conf_path` has a value that is the path to
the OpenSSL config file.

175
tests/wpt/web-platform-tests/docs/css-metadata.md
View file

@ -1,125 +1,4 @@
CSS tests have some particular requirements for metadata.
## Title element
``` html
<title>[Test Area]: [Title/Scope of Test]</title>
or
<title>[Test Area] Reference File</title>
```
The title appears in the generated index, so make sure it is
concise and descriptive. The role of the title is to
identify what specific detail of a feature or combination of
features is being tested, so that someone looking through an index
can see quickly what's tested in which file. In most cases, this
description should not require more than 5 or 6 words. There is no
need to provide the chapter or section in the title. For reference
file, the titles should not be specific to a test case as these
files may be used by multiple different tests.
Bad examples:
``` html
<title>CSS Test: Border Conflict Resolution</title>
<title>CSS Regions auto-height Reference</title>
```
Good examples:
``` html
<title>CSS Test: Border Conflict Resolution (width) - hidden/double
</title>
<title>CSS Reference File</title>
```
For CSS specifications other than CSS 2.1, you can include the
module name somewhere before the colon, like "CSS Selectors Test:"
or "CSS Test (Selectors):". Do not include the module version
number, since the test might get reused for the next version.
### Credits
``` html
<link rel="author" title="NAME_OF_AUTHOR"
href="[mailto:some@address or http://some.url]" />
```
Credits provide a way to identify the person or organization that
created the test and/or holds copyright in the test. This is useful
for reviewing purposes and for asking questions about the individual
test. A test can have multiple author credits if necessary.
Example 1:
``` html
<link rel="author" title="Boris Zbarsky"
href="mailto:bzbarsky@mit.edu" />
```
Example 2:
``` html
<link rel="author" title="Bert Bos"
href="http://www.w3.org/People/Bos/" />
```
Example 3:
``` html
<link rel="author" title="Microsoft" href="http://microsoft.com/" />
```
### Reviewer
``` html
<link rel="reviewer" title="NAME_OF_REVIEWER" href="[mailto:some@address
or http://some.url]" /> <!-- YYYY-MM-DD -->
```
If a test has passed review, then the reviewer should note this by
adding his or her name as a reviewer, along with the date of the
review. A test can have multiple reviewers if necessary. A reviewer
must be a person, not an organization.
Example 1:
``` html
<link rel="reviewer" title="Boris Zbarsky"
href="mailto:bzbarsky@mit.edu" /> <!-- 2008-02-19 -->
```
Example 2:
``` html
<link rel="reviewer" title="Bert Bos"
href="http://www.w3.org/People/Bos/" /> <!-- 2005-05-03 -->
```
If a test would pass review with some (non-metadata) changes and the
reviewer chooses to make these changes, then the reviewer should add
his or her name as a reviewer-author, along with the date of the
review, when checking in those changes. This indicates that the
reviewer-author approves of the original author's test when taken
with these proposed changes, and that someone else (possibly the
original author) must review the changes. The test is fully reviewed
only when the latest reviewer did not also contribute changes to the
test at the time of the review.
Example of a fully-reviewed test:
``` html
<link rel="author" title="Bert Bos"
href="http://www.w3.org/People/Bos/" />
<link rel="reviewer author" title="Boris Zbarsky"
href="mailto:bzbarsky@mit.edu" /> <!-- 2008-02-19 -->
<link rel="reviewer" title="Bert Bos"
href="http://www.w3.org/People/Bos/" /> <!-- 2008-04-22 -->
```
This test was written by Bert Bos, then reviewed by Boris Zbarsky,
who made some corrections before deeming it acceptable. Those
corrections were then reviewed and accepted by Bert Bos.
CSS tests have some additional requirements for metadata.
### Specification Links
@ -163,58 +42,6 @@ href="http://www.w3.org/TR/CSS21/visudet.html#line-height" />
href="http://www.w3.org/TR/CSS21/colors.html#background-properties" />
```
### Reference Links
*Reftests only*
``` html
<link rel="match" href="RELATIVE_PATH_TO_REFERENCE_FILE" />
<link rel="mismatch" href="RELATIVE_PATH_TO_REFERENCE_FILE" />
```
The reference link elements are used in reftests and provide
the list of reference file(s) that the test should be compared to.
* ```match``` references must be files that render identically to
the test, but use an alternate means to do so
* Multiple match references are used when the test can match any of
the reference files
* If a test requires multiple match references that all need to
match (for example, to catch when a reference fails in the same
way the test does), then chain the references together, i.e.:
place reference links to the additional match references in the
reference files. It is recommended that the chained reference
files form a loop (e.g.: a → b → c → a) so that a test linking
to any reference in the chain will find all the references.
* ```mismatch``` references are files that render differently than
the test file. A test may have any number of mismatch references.
The test is considered to fail if it renders the same as any of
the mismatch references.
* Note that reference files may themselves have mismatch
references. In that case the reference file must not render the
same as any of its mismatch references in order to be considered
valid. If a reference is considered invalid (by the fact of not
matching any of its match references, or matching any of its
mismatch references), then a test that refers to the reference
will be considered to have failed.
* Reference files may be dedicated reference files, images, or other
tests
Example 1:
``` html
<link rel="match" href="green-box-ref.xht" />
```
Example 2:
``` html
<link rel="match" href="green-box-ref.xht" />
<link rel="match" href="blue-box-ref.xht" />
<link rel="mismatch" href="red-box-notref.xht" />
<link rel="mismatch" href="red-box-notref.xht" />
```
### Requirement Flags
<table>

17
tests/wpt/web-platform-tests/docs/review-process.md
View file

@ -21,22 +21,6 @@ All new code submissions must use the GitHub pull request
workflow. The GitHub UI for code review may be used, but other tools
may also be used as long as the review is clearly linked.
### Critic
[Critic][critic] is a code review tool that is frequently used for
reviewing web-platform-tests submissions. Although it has a steeper
learning curve than the GitHub tools, it has more features that aid in
conducting non-trivial reviews.
If you want to use Critic to review code, visit the [homepage][critic]
and log (authentication is via GitHub). On the homepage, click "Add
Filter". In the resulting dialog, select the web-platform-tests
repository and add the path of the folder(s) where you want to review
code, e.g. `/` to review any submissions or `XMLHttpRequest/` to
review only submissions in the `XHMLHttpRequest` directory. Ensure that
your email address is added so that you receive notifications of new
reviews matching your filters, and activity on existing reviews.
## Labels
Pull requests get automatically labelled in the GitHub repository. Check
@ -53,4 +37,3 @@ shows the number of open review requests, and can be filtered by testsuite.
[style]: ./test-style-guidelines.html
[review-checklist]: ./review-checklist.html
[issues]: https://github.com/w3c/web-platform-tests/issues
[critic]: https://critic.hoppipolla.co.uk