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

docs/testing/writing_layout_tests.md

 # Writing Layout Tests
 
 _Layout tests_ is a bit of a misnomer. This term is
 [a part of our WebKit heritage](https://webkit.org/blog/1452/layout-tests-theory/),
 and we use it to refer to every test that is written as a Web page (HTML, SVG,
 or XHTML) and lives in
 [third_party/WebKit/LayoutTests/](../../third_party/WebKit/LayoutTests).
 
 [TOC]
 
 ## Overview
 
 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

[pwnall, 2017/02/16 19:10:40]

do we still use WPT, or should we use wpt for web-platform-tests?

[foolip, 2017/02/16 19:18:58]

I have consulted my inbox and see people using both forms, although James Graham
says wpt :)

This CL is just about to land and I'm going to be OOO until Tuesday, if you'd
like to s/WPT/wpt/ here and in layout_tests_tips.md, that would be great.

+   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),
    the feature must be covered by layout tests, to avoid unexpected regressions.
    These tests will use Blink-specific testing APIs that are only available in
    [content_shell](./layout_tests_in_content_shell.md).
 
 *** promo
 If you know that Blink layout tests are upstreamed to other projects, such as
 [test262](https://github.com/tc39/test262), please update this document. Most
@@ skipping 34 matching lines @@
   test passes if the output matches a baseline text file in the repository.
   Layout tree tests are used as a last resort to test the internal quirks of
   the implementation, and they should be avoided in favor of one of the earlier
   options.
 
 ## General Principles
 
 
 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
 have adopted style guides, such as the
 [ServiceWorker Tests Style guide](https://www.chromium.org/blink/serviceworker/testing).
 
 Our [document on layout tests tips](./layout_tests_tips.md) summarizes the most
 important WPT guidelines and highlights some JavaScript concepts that are worth
 paying attention to when trying to infer style rules from existing tests. If
 you're unopinionated and looking for a style guide to follow, the document also
 suggests some defaults.
 
 ## JavaScript Tests
 
 Whenever possible, the testing criteria should be expressed in JavaScript. The
 alternatives, which will be described in future sections, result in slower and
 less reliable tests.
 
 All new JavaScript tests should be written using the
 [testharness.js](https://github.com/w3c/testharness.js/) testing framework. This
 framework is used by the tests in the
 [web-platform-tests](https://github.com/w3c/web-platform-tests) repository,
 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.
 
 Below is a skeleton for a JavaScript test embedded in an HTML page. Note that,
 in order to follow the minimality guideline, the test omits the tags `<html>`,
 `<head>`, and `<body>`, as they can be inferred by the HTML parser.
 
 ```html
 <!doctype html>
 <title>JavaScript: the true literal is immutable and equal to itself</title>
@@ skipping 227 matching lines @@
 Reference tests, also known as reftests, perform a pixel-by-pixel comparison
 between the rendered image of a test page and the rendered image of a reference
 page. Most reference tests pass if the two images match, but there are cases
 where it is useful to have a test pass when the two images do _not_ match.
 
 Reference tests are more difficult to debug than JavaScript tests, and tend to
 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
   passes when the test image matches or does not match the reference image.
 * The reference page must not use the feature being tested. Otherwise, the test
   is meaningless.
 * The reference page should be as simple as possible, and should not depend on
   advanced features. Ideally, the reference page should render as intended even
   on browsers with poor CSS support.
 * Reference tests should be self-describing.
@@ skipping 51 matching lines @@
 `window.testRunner.dumpDragImage()` create an image result that is associated
 with the test. The image result is compared against an image baseline, which is
 an `-expected.png` file associated with the test, and the test passes if the
 image result is identical to the baseline, according to a pixel-by-pixel
 comparison. Tests that have image results (and baselines) are called **pixel
 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.
   If that is not possible, make the test self-describing by including a textual
   description of the desired (passing) outcome.
 * Only use the red color or the word `FAIL` to highlight errors. This does not
   apply when testing the color red.
 * &#x1F6A7; Use the
   [Ahem font](https://www.w3.org/Style/CSS/Test/Fonts/Ahem/README) to reduce the
   variance introduced by the platform's text rendering system. This does not
@@ skipping 135 matching lines @@
 * The `http/` directory hosts tests that require an HTTP server (see above).
 * The `resources/` subdirectory in every directory contains binary files, such
   as media files, and code that is shared by multiple test files.
 
 *** note
 Some layout tests consist of a minimal HTML page that references a JavaScript
 file in `resources/`. Please do not use this pattern for new tests, as it goes
 against the minimality principle. JavaScript and CSS files should only live in
 `resources/` if they are shared by at least two test files.
 ***