jiangcuo/node
1
0
Fork 0
mirror of https://github.com/nodejs/node.git synced 2025-04-28 13:40:37 +00:00
Code Issues Actions 20 Packages Projects Releases Wiki Activity

doc: recommend writing tests in new files and including comments

Browse Source 
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: https://github.com/nodejs/node/pull/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>
This commit is contained in:
Joyee Cheung 2025-02-15 13:58:08 +01:00 committed by GitHub
parent 44e2671b44
commit ff51d83c96
No known key found for this signature in database
GPG Key ID: B5690EEEBB952194
1 changed files with 16 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

19
doc/contributing/writing-tests.md
View File

@ -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