Skip to content

Commit ff51d83

Browse files
authored
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: nodejs#57028 Reviewed-By: James M Snell <[email protected]> Reviewed-By: Richard Lau <[email protected]> Reviewed-By: Michaël Zasso <[email protected]> Reviewed-By: Ulises Gascón <[email protected]> Reviewed-By: Luigi Pinca <[email protected]> Reviewed-By: Jake Yuesong Li <[email protected]> Reviewed-By: Chengzhong Wu <[email protected]> Reviewed-By: Tierney Cyren <[email protected]>
1 parent 44e2671 commit ff51d83

File tree

1 file changed

+16
-3
lines changed

1 file changed

+16
-3
lines changed

doc/contributing/writing-tests.md

+16-3
Original file line numberDiff line numberDiff line change
@@ -21,9 +21,22 @@ Add tests when:
2121
## Test directory structure
2222

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

2841
## Test structure
2942

0 commit comments

Comments
 (0)