chromium/src
0
Fork 0
Code Activity

Link to new web-platform-tests.org documentation from our own

Browse Source 
Many pages of testthewebforward.org now redirect, so replace links with
something appropriate from the new documentation.

Since the new documentation consistently says "web-platform-tests"
instead of "Web Platform Tests" and this is what folks like jgraham tend
to write as well, align our own usage with that.

BUG=657117

Review-Url: https://codereview.chromium.org/2696323003
Cr-Commit-Position: refs/heads/master@{#451045}
This commit is contained in:
foolip
2017-02-16 11:21:58 -08:00
committed by Commit bot
parent 920466c7eb
commit eda32ab004
7 changed files with 36 additions and 36 deletions

4
docs/testing/layout_tests.md

@ -462,10 +462,10 @@ test is being re-baselined. If this is a special case (i.e., something we've
decided to be different with upstream), please put a README file next to the new
expected output explaining the difference.
## Web Platform Tests
## web-platform-tests
In addition to layout tests developed and run just by the Blink team, there is
also a shared test suite, see [Web Platform Tests](./web_platform_tests.md).
also a shared test suite, see [web-platform-tests](./web_platform_tests.md).
## Known Issues

4
docs/testing/layout_tests_tips.md

@ -20,7 +20,7 @@ capture the context that rests in the head of an experienced Blink engineer.
## General Principles
This section contains guidelines adopted from
[Test the Web Forward's Test Format Guidelines](http://testthewebforward.org/docs/test-format-guidelines.html)
[web-platform-tests documentation](http://web-platform-tests.org/writing-tests/general-guidelines.html)
and
[WebKit's Wiki page on Writing good test cases](https://trac.webkit.org/wiki/Writing%20Layout%20Tests%20for%20DumpRenderTree),
with Blink-specific flavoring.
@ -93,7 +93,7 @@ feature being tested.
`testharness.js` makes a test self-describing when used correctly. Other types
of tests, such as reference tests and
[tests with manual fallback](./layout_tests_with_manual_fallback.md),
[must be carefully designed](http://testthewebforward.org/docs/test-style-guidelines.html)
[must be carefully designed](http://web-platform-tests.org/writing-tests/manual.html#requirements-for-a-manual-test)
to be self-describing.
### Minimal

4
docs/testing/layout_tests_with_manual_fallback.md

@ -11,7 +11,7 @@ normal browser session.
A popular pattern used in these tests is to rely on the user to perform some
manual steps in order to run the test case in a normal browser session. These
tests are effectively
[manual tests](http://testthewebforward.org/docs/manual-test.html), with
[manual tests](http://web-platform-tests.org/writing-tests/manual.html), with
additional JavaScript code that automatically performs the desired manual steps,
when loaded in an environment that exposes the needed testing APIs.
@ -26,7 +26,7 @@ the following benefits.
* The manual tests can run in other browsers, making it easy to check whether
our behavior matches other browsers.
* The layout tests can form the basis for manual tests that are contributed to
the [Web Platform Tests Project](https://github.com/w3c/web-platform-tests).
[web-platform-tests](./web_platform_tests.md).
Therefore, the desirability of adding a manual fallback to a test heavily
depends on whether the feature under test is a Web Platform feature or a

23
docs/testing/web_platform_tests.md

@ -1,4 +1,4 @@
# Web Platform Tests
# web-platform-tests
Interoperability between browsers is
[critical](https://www.chromium.org/blink/platform-predictability) to Chromium's
@ -16,6 +16,9 @@ repository, where tests are imported into
[LayoutTests/external/wpt](../../third_party/WebKit/LayoutTests/external/wpt)
and any changes to the imported tests are also exported to web-platform-tests.
See http://web-platform-tests.org/ for general documentation on
web-platform-tests, including tips for writing and reviewing tests.
[TOC]
## Importing tests
@ -26,15 +29,15 @@ Chromium has mirrors
GitHub repos, and periodically imports a subset of the tests so that they are
run as part of the regular Blink layout test testing process.
The goal of this process are to be able to run Web Platform Tests unmodified
The goal of this process are to be able to run web-platform-tests unmodified
locally just as easily as we can run the Blink tests, and ensure that we are
tracking tip-of-tree in the Web Platform Tests repository as closely as
tracking tip-of-tree in the web-platform-tests repository as closely as
possible, and running as many of the tests as possible.
### Automatic import process
There is an automatic process for updating the Chromium copy of the Web Platform
Tests. The import is done by the builder [w3c-test-autoroller
There is an automatic process for updating the Chromium copy of
web-platform-tests. The import is done by the builder [w3c-test-autoroller
builder](https://build.chromium.org/p/chromium.infra.cron/builders/w3c-test-autoroller).
The easiest way to check the status of recent imports is to look at:
@ -79,7 +82,7 @@ you can also run `wpt-import --allow-local-commits`, but this is not required.
## Writing tests
To contribute changes to Web Platform Tests, just commit your changes directly
To contribute changes to web-platform-tests, just commit your changes directly
to [LayoutTests/external/wpt](../../third_party/WebKit/LayoutTests/external/wpt)
and the changes will be automatically upstreamed within 24 hours.
@ -104,7 +107,7 @@ Most tests are written using testharness.js, see
### Write tests against specifications
Tests in Web Platform Tests are expected to match behavior defined by the
Tests in web-platform-tests are expected to match behavior defined by the
relevant specification. In other words, all assertions that a test makes
should be derived from a specification's normative requirements, and not go
beyond them. It is often necessary to change the specification to clarify what
@ -155,10 +158,8 @@ resolve the conflict.
### Direct pull requests
It's still possible to make direct pull requests to web-platform-tests. The
processes for getting new tests committed the W3C repos are at
http://testthewebforward.org/docs/. Some specifics are at
http://testthewebforward.org/docs/github-101.html.
It's still possible to make direct pull requests to web-platform-tests, see
http://web-platform-tests.org/appendix/github-intro.html.
## Reviewing tests

31
docs/testing/writing_layout_tests.md

@ -13,13 +13,12 @@ or XHTML) and lives in
Layout tests should be used to accomplish one of the following goals:
1. The entire surface of Blink that is exposed to the Web should be covered by
tests that we contribute to the
[Web Platform Tests Project](./web_platform_tests.md) (WPT). This helps us
avoid regressions, and helps us identify Web Platform areas where the major
browsers don't have interoperable implementations. Furthermore, by
contributing to projects such as WPT, we share the burden of writing tests
with the other browser vendors, and we help all the browsers get better. This
is very much in line with our goal to move the Web forward.
tests that we contribute to [web-platform-tests](./web_platform_tests.md)
(WPT). This helps us avoid regressions, and helps us identify Web Platform
areas where the major browsers don't have interoperable implementations.
Furthermore, by contributing to projects such as WPT, we share the burden of
writing tests with the other browser vendors, and we help all the browsers
get better. This is very much in line with our goal to move the Web forward.
2. When a Blink feature cannot be tested using the tools provided by WPT, and
cannot be easily covered by
[C++ unit tests](https://cs.chromium.org/chromium/src/third_party/WebKit/Source/web/tests/?q=webframetest&sq=package:chromium&type=cs),
@ -74,7 +73,7 @@ There are four broad types of layout tests, listed in the order of preference.
Tests should be written under the assumption that they will be upstreamed
to the WPT project. To this end, tests should follow the
[WPT guidelines](http://testthewebforward.org/docs/writing-tests.html).
[WPT guidelines](http://web-platform-tests.org/writing-tests/).
There is no style guide that applies to all layout tests. However, some projects
@ -100,12 +99,12 @@ framework is used by the tests in the
which is shared with all the other browser vendors, so `testharness.js` tests
are more accessible to browser developers.
As a shared framework, `testharness.js` enjoys high-quality documentation, such
as [a tutorial](http://testthewebforward.org/docs/testharness-tutorial.html) and
[API documentation](https://github.com/w3c/testharness.js/blob/master/docs/api.md).
Layout tests should follow the recommendations of the above documents.
See the [API documentation](https://github.com/w3c/testharness.js/blob/master/docs/api.md)
for a thorough introduction to `testharness.js`.
Layout tests should follow the recommendations of the above documentation.
Furthermore, layout tests should include relevant
[metadata](http://testthewebforward.org/docs/css-metadata.html). The
[metadata](http://web-platform-tests.org/writing-tests/css-metadata.html). The
specification URL (in `<link rel="help">`) is almost always relevant, and is
incredibly helpful to a developer who needs to understand the test quickly.
@ -353,8 +352,8 @@ be slower as well. Therefore, they should only be used for functionality that
cannot be covered by JavaScript tests.
New reference tests should follow the
[WPT reftests guidelines](http://testthewebforward.org/docs/reftests.html). The
most important points are summarized below.
[WPT reftests guidelines](http://web-platform-tests.org/writing-tests/reftests.html).
The most important points are summarized below.
* &#x1F6A7; The test page declares the reference page using a
`<link rel="match">` or `<link rel="mismatch">`, depending on whether the test
@ -426,7 +425,7 @@ tests**.
Pixel tests should still follow the principles laid out above. Pixel tests pose
unique challenges to the desire to have *self-describing* and *cross-platform*
tests. The
[WPT test style guidelines](http://testthewebforward.org/docs/test-style-guidelines.html)
[WPT rendering test guidelines](http://web-platform-tests.org/writing-tests/rendering.html)
contain useful guidance. The most relevant pieces of advice are below.
* Whenever possible, use a green paragraph / page / square to indicate success.

2
third_party/WebKit/Source/core/dom/custom/README.md vendored

@ -86,7 +86,7 @@ The custom element layout tests are generally in
third_party/WebKit/LayoutTests/custom-elements.
All custom elements layout tests use the [W3C web-platform-tests
harness](http://testthewebforward.org/docs/) and follow its style. The
harness](http://web-platform-tests.org/) and follow its style. The
W3C is not very prescriptive, so be consistent with other custom
elements tests.

4
third_party/WebKit/Tools/Scripts/webkitpy/w3c/test_copier.py vendored

@ -108,11 +108,11 @@ class TestCopier(object):
jstests = 0
# Files in 'tools' are not for browser testing, so we skip them.
# See: http://testthewebforward.org/docs/test-format-guidelines.html#tools
# See: http://web-platform-tests.org/writing-tests/general-guidelines.html#tools
dirs_to_skip = ('.git', 'test-plan', 'tools')
# We copy all files in 'support', including HTML without metadata.
# See: http://testthewebforward.org/docs/test-format-guidelines.html#support-files
# See: http://web-platform-tests.org/writing-tests/general-guidelines.html#support-files
dirs_to_include = ('resources', 'support')
if dirs: