Adding upstream version 110.0.1.upstream/110.0.1upstream

Signed-off-by: Daniel Baumann <daniel.baumann@progress-linux.org>

1 files changed, 91 insertions, 0 deletions

diff --git a/testing/web-platform/tests/docs/writing-tests/index.md b/testing/web-platform/tests/docs/writing-tests/index.md
new file mode 100644
index 0000000000..e5739c9a6e
--- /dev/null
+++ b/testing/web-platform/tests/docs/writing-tests/index.md
@@ -0,0 +1,91 @@
+# Writing Tests
+
+So you'd like to write new tests for WPT? Great! For starters, we recommend
+reading [the introduction](../index) to learn how the tests are organized and
+interpreted. You might already have an idea about what needs testing, but it's
+okay if you don't know where to begin. In either case, [the guide on making a
+testing plan](making-a-testing-plan) will help you decide what to write.
+
+There's also a load of [general guidelines](general-guidelines) that apply to all tests.
+
+## Test Types
+
+There are various different ways of writing tests:
+
+* [JavaScript tests (testharness.js)](testharness) are preferred for testing APIs and may be used
+  for other features too. They are built with the testharness.js unit testing framework, and consist
+  of assertions written in JavaScript. A high-level [testharness.js tutorial](testharness-tutorial)
+  is available.
+
+* Rendering tests should be used to verify that the browser graphically
+  displays pages as expected. See the [rendering test guidelines](rendering)
+  for tips on how to write great rendering tests. There are a few different
+  ways to write rendering tests:
+
+  * [Reftests](reftests) should be used to test rendering and layout. They
+    consist of two or more pages with assertions as to whether they render
+    identically or not. A high-level [reftest tutorial](reftest-tutorial) is available. A
+    [print reftests](print-reftests) variant is available too.
+
+  * [Visual tests](visual) should be used for checking rendering where there is
+    a large number of conforming renderings such that reftests are impractical.
+    They consist of a page that renders to final state at which point a
+    screenshot can be taken and compared to an expected rendering for that user
+    agent on that platform.
+
+* [Crashtests](crashtest) tests are used to check that the browser is
+  able to load a given document without crashing or experiencing other
+  low-level issues (asserts, leaks, etc.). They pass if the load
+  completes without error.
+
+* [wdspec](wdspec) tests are written in Python using
+  [pytest](https://docs.pytest.org/en/latest/) and test [the WebDriver browser
+  automation protocol](https://w3c.github.io/webdriver/)
+
+* [Manual tests](manual) are used as a last resort for anything that can't be
+  tested using any of the above. They consist of a page that needs manual
+  interaction or verification of the final result.
+
+See [file names](file-names) for test types and features determined by the file names,
+and [server features](server-features) for advanced testing features.
+
+## Submitting Tests
+
+Once you've written tests, please submit them using
+the [typical GitHub Pull Request workflow](submission-process); please
+make sure you run the [`lint` script](lint-tool) before opening a pull request!
+
+## Table of Contents
+
+```eval_rst
+.. toctree::
+   :maxdepth: 1
+
+   general-guidelines
+   making-a-testing-plan
+   testharness
+   testharness-tutorial
+   rendering
+   reftests
+   reftest-tutorial
+   print-reftests
+   visual
+   crashtest
+   wdspec
+   manual
+   file-names
+   server-features
+   submission-process
+   lint-tool
+   ahem
+   assumptions
+   css-metadata
+   css-user-styles
+   h2tests
+   testdriver
+   testdriver-extension-tutorial
+   tools
+   test-templates
+   github-intro
+   ../tools/webtransport/README.md
+```