Commit f0c6c690 authored by ktyliu's avatar ktyliu Committed by Commit bot

Remove <title> in writing_layout_tests documentation as it

doesn't appear in test results (thanks to Alan for pointing it out).

Instead we should focus on writing good test descriptions.

BUG=

Review-Url: https://codereview.chromium.org/2617083002
Cr-Commit-Position: refs/heads/master@{#441876}
parent d6dfbbf1
...@@ -338,7 +338,6 @@ in order to follow the minimality guideline, the test omits the tags `<html>`, ...@@ -338,7 +338,6 @@ in order to follow the minimality guideline, the test omits the tags `<html>`,
```html ```html
<!doctype html> <!doctype html>
<meta charset="utf-8"> <meta charset="utf-8">
<title>JavaScript: the true literal</title>
<link rel="help" href="https://tc39.github.io/ecma262/#sec-boolean-literals"> <link rel="help" href="https://tc39.github.io/ecma262/#sec-boolean-literals">
<meta name="assert" value="The true literal is equal to itself and immutable"> <meta name="assert" value="The true literal is equal to itself and immutable">
<script src="/resources/testharness.js"></script> <script src="/resources/testharness.js"></script>
...@@ -375,9 +374,7 @@ promise_test(() => { ...@@ -375,9 +374,7 @@ promise_test(() => {
Some points that are not immediately obvious from the example: Some points that are not immediately obvious from the example:
* The `<meta name="assert">` describes the purpose of the entire file, and * The `<meta name="assert">` describes the purpose of the entire file.
is not redundant to `<title>`. Don't add a `<meta name="assert">` when the
information in the `<title>` is sufficient.
* When calling an `assert_` function that compares two values, the first * When calling an `assert_` function that compares two values, the first
argument is the actual value (produced by the functionality being tested), and argument is the actual value (produced by the functionality being tested), and
the second argument is the expected value (known good, golden). The order the second argument is the expected value (known good, golden). The order
...@@ -393,9 +390,6 @@ Some points that are not immediately obvious from the example: ...@@ -393,9 +390,6 @@ Some points that are not immediately obvious from the example:
redundant. redundant.
* Do not start test case descriptions with redundant terms like "Testing" * Do not start test case descriptions with redundant terms like "Testing"
or "Test for". or "Test for".
* Test files with a single test case should omit the test case description.
The file's `<title>` should be sufficient to describe the scenario being
tested.
* Asynchronous tests have a few subtleties. * Asynchronous tests have a few subtleties.
* The `async_test` wrapper calls its function with a test case argument that * The `async_test` wrapper calls its function with a test case argument that
is used to signal when the test case is done, and to connect assertion is used to signal when the test case is done, and to connect assertion
...@@ -516,7 +510,6 @@ Below is an example of a fairly minimal test that uses a Blink-Specific API ...@@ -516,7 +510,6 @@ Below is an example of a fairly minimal test that uses a Blink-Specific API
```html ```html
<!doctype html> <!doctype html>
<meta charset="utf-8"> <meta charset="utf-8">
<title>DOM: Event.isTrusted for UI events</title>
<link rel="help" href="https://dom.spec.whatwg.org/#dom-event-istrusted"> <link rel="help" href="https://dom.spec.whatwg.org/#dom-event-istrusted">
<link rel="help" href="https://dom.spec.whatwg.org/#constructing-events"> <link rel="help" href="https://dom.spec.whatwg.org/#constructing-events">
<meta name="assert" <meta name="assert"
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment