doc: recommend writing tests in new files and including comments

The previous phrasing encouraged or did not discourage appending
new test cases to existing files - a practice that can reduce
the debuggability of the tests over time as they get bigger and
bigger, some times thousands of lines long with hundreds of
test cases, and make the CI output increasingly difficult to
read when one of the test cases fail in a very long test.

This patch updates the guideline to explicitly discourage appending
test cases this way. Also recommend including an opening comment
to describe what the test does to optimize the test towards the
scenario when it fails.

PR-URL: #57028
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Richard Lau <rlau@redhat.com>
Reviewed-By: Michaël Zasso <targos@protonmail.com>
Reviewed-By: Ulises Gascón <ulisesgascongonzalez@gmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: Jake Yuesong Li <jake.yuesong@gmail.com>
Reviewed-By: Chengzhong Wu <legendecas@gmail.com>
Reviewed-By: Tierney Cyren <hello@bnb.im>

Author: joyeecheung

doc/contributing/writing-tests.md

@@ -21,9 +21,22 @@ Add tests when:
 ## Test directory structure
 
 See [directory structure overview][] for outline of existing test and locations.
-When deciding on whether to expand an existing test file or create a new one,
-consider going through the files related to the subsystem.
-For example, look for `test-streams` when writing a test for `lib/streams.js`.
+
+## How to write a good test
+
+A good test should be written in a style that is optimial for debugging
+when it fails.
+
+In principle, when adding a new test, it should be placed in a new file.
+Unless there is strong motivation to do so, refrain from appending
+new test cases to an existing file. Similar to the reproductions we ask
+for in the issue tracker, a good test should be as minimal and isolated as
+possible to facilitate debugging.
+
+A good test should come with comments explaining what it tries to test,
+so that when it fails, other contributors can fix it with the full context
+of its intention, and be able to modify it in good confidence when the context
+changes.
 
 ## Test structure