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

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}

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
 

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

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

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
+There is an automatic process for updating the Chromium copy of
-Tests. The import is done by the builder [w3c-test-autoroller
+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
+It's still possible to make direct pull requests to web-platform-tests, see
-processes for getting new tests committed the W3C repos are at
+http://web-platform-tests.org/appendix/github-intro.html.
-http://testthewebforward.org/docs/. Some specifics are at
-http://testthewebforward.org/docs/github-101.html.
 
 ## Reviewing tests
 

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
+   tests that we contribute to [web-platform-tests](./web_platform_tests.md)
-   [Web Platform Tests Project](./web_platform_tests.md) (WPT). This helps us
+   (WPT). This helps us avoid regressions, and helps us identify Web Platform
-   avoid regressions, and helps us identify Web Platform areas where the major
+   areas where the major browsers don't have interoperable implementations.
-   browsers don't have interoperable implementations. Furthermore, by
+   Furthermore, by contributing to projects such as WPT, we share the burden of
-   contributing to projects such as WPT, we share the burden of writing tests
+   writing tests with the other browser vendors, and we help all the browsers
-   with the other browser vendors, and we help all the browsers get better. This
+   get better. This is very much in line with our goal to move the Web forward.
-   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
+See the [API documentation](https://github.com/w3c/testharness.js/blob/master/docs/api.md)
-as [a tutorial](http://testthewebforward.org/docs/testharness-tutorial.html) and
+for a thorough introduction to `testharness.js`.
-[API documentation](https://github.com/w3c/testharness.js/blob/master/docs/api.md).
+
-Layout tests should follow the recommendations of the above documents.
+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
+[WPT reftests guidelines](http://web-platform-tests.org/writing-tests/reftests.html).
-most important points are summarized below.
+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.

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

@@ -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.
 

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

@@ -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: