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

docs/testing/layout_tests_tips.md

 # Layout Tests Tips
 
 The recommendations here are intended to help you write new tests that go
 through code review with a minimal number of round trips, remain useful as Blink
 evolves, and serve as an asset (rather than a liability) for the team.
 
 While reading existing layout tests, please keep in mind that they represent
 snapshots taken over many years of an ever-evolving collective opinion of what
 good Web pages and solid tests should look like. Thus, it should not come as a
 surprise that most existing layout tests are not consistent with these
 recommendations, and are not even consistent with each other.
 
 *** note
 This document intentionally uses _should_ a lot more than _must_, as defined in
 [RFC 2119](https://www.ietf.org/rfc/rfc2119.txt). Writing layout tests is a
 careful act of balancing many concerns, and this humble document cannot possibly
 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.
 
 ### Concise
 
 Tests should be **concise**, without compromising on the principles below. Every
 element and piece of code on the page should be necessary and relevant to what
 is being tested. For example, don't build a fully functional signup form if you
 only need a text field or a button.
@@ skipping 52 matching lines @@
 
 ### Self-Describing
 
 Tests should be **self-describing**, so that a project member can recognize
 whether a test passes or fails without having to read the specification of the
 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
 
 Tests should require a **minimal** amount of cognitive effort to read and
 maintain.
 
 Avoid depending on edge case behavior of features that aren't explicitly covered
 by the test. For example, except where testing parsing, tests should contain
 valid markup (no parsing errors).
@@ skipping 185 matching lines @@
 
 Tests that rely on the testing APIs exposed by WPT or Blink will not work when
 loaded in a standard browser environment. When writing such tests, default to
 having the tests gracefully degrade to manual tests in the absence of the
 testing APIs.
 
 The
 [document on layout tests with manual feedback](./layout_tests_with_manual_fallback.md)
 describes the approach in detail and highlights the trade-off between added test
 weight and ease of debugging.