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

docs/testing/layout_tests_with_manual_fallback.md

 # Layout Tests with Manual Fallback
 
 Some Blink features cannot be automatically tested using the Web Platform. Prime
 examples are the APIs that require
 [user activation](https://html.spec.whatwg.org/multipage/interaction.html#triggered-by-user-activation)
 (also known as _a user gesture_), such as [Full Screen](https://developer.mozilla.org/en-US/docs/Web/API/Fullscreen_API).
 Automated tests for these Blink features must rely on special APIs, which are
 only exposed in testing environments, and are therefore not available in a
 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.
 
 ## Motivation
 
 Layout tests that degrade to manual tests in the absence of testing APIs have
 the following benefits.
 
 * The manual test component can be debugged in a normal browser session, using
   the rich [developer tools](https://developer.chrome.com/devtools). Tests
   without a manual fallback can only be debugged in the test runner.
 * 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
 Blink-only feature, and on the developer's working style. The benefits above
 should be weighed against the added design effort needed to build a manual test,
 and the size and complexity introduced by the manual fallback.
 
 ## Development Tips
 
 A natural workflow for writing a layout test that gracefully degrades to a
@@ skipping 70 matching lines @@
   fail when the APIs are not present.
 * It uses [Promises](https://developer.mozilla.org/docs/Web/JavaScript/Reference/Global_Objects/Promise)
   to separate the test setup from the assertions. This is particularly helpful
   for manual tests that depend on a sequence of events to occur, as Promises
   offer a composable way to express waiting for asynchronous events that avoids
   [callback hell](http://stackabuse.com/avoiding-callback-hell-in-node-js/).
 
 Notice that the test is pretty heavy compared to a minimal JavaScript test that
 does not rely on testing APIs. Only use testing APIs when the desired testing
 conditions cannot be set up using Web Platform APIs.