@@ -15,7 +15,6 @@ so that you can make the actual changes. This is where we will start.
15
15
* [ Commit message guidelines] ( #commit-message-guidelines )
16
16
* [ Step 5: Rebase] ( #step-5-rebase )
17
17
* [ Step 6: Test] ( #step-6-test )
18
- * [ Test Coverage] ( #test-coverage )
19
18
* [ Step 7: Push] ( #step-7-push )
20
19
* [ Step 8: Opening the Pull Request] ( #step-8-opening-the-pull-request )
21
20
* [ Step 9: Discuss and Update] ( #step-9-discuss-and-update )
@@ -237,75 +236,7 @@ And on Windows:
237
236
> vcbuild test
238
237
```
239
238
240
- (See the [ Building guide] [ ] for more details.)
241
-
242
- Make sure the linter does not report any issues and that all tests pass. Please
243
- do not submit patches that fail either check.
244
-
245
- If you want to run the linter without running tests, use
246
- ` make lint ` /` vcbuild lint ` . It will run both JavaScript linting and
247
- C++ linting.
248
-
249
- If you are updating tests and just want to run a single test to check it:
250
-
251
- ``` text
252
- $ python tools/test.py -J --mode=release parallel/test-stream2-transform
253
- ```
254
-
255
- You can execute the entire suite of tests for a given subsystem
256
- by providing the name of a subsystem:
257
-
258
- ``` text
259
- $ python tools/test.py -J --mode=release child-process
260
- ```
261
-
262
- If you want to check the other options, please refer to the help by using
263
- the ` --help ` option
264
-
265
- ``` text
266
- $ python tools/test.py --help
267
- ```
268
-
269
- You can usually run tests directly with node:
270
-
271
- ``` text
272
- $ ./node ./test/parallel/test-stream2-transform.js
273
- ```
274
-
275
- Remember to recompile with ` make -j4 ` in between test runs if you change code in
276
- the ` lib ` or ` src ` directories.
277
-
278
- #### Test Coverage
279
-
280
- It's good practice to ensure any code you add or change is covered by tests.
281
- You can do so by running the test suite with coverage enabled:
282
-
283
- ``` text
284
- $ ./configure --coverage && make coverage
285
- ```
286
-
287
- A detailed coverage report will be written to ` coverage/index.html ` for
288
- JavaScript coverage and to ` coverage/cxxcoverage.html ` for C++ coverage.
289
-
290
- _ Note that generating a test coverage report can take several minutes._
291
-
292
- To collect coverage for a subset of tests you can set the ` CI_JS_SUITES ` and
293
- ` CI_NATIVE_SUITES ` variables:
294
-
295
- ``` text
296
- $ CI_JS_SUITES=child-process CI_NATIVE_SUITES= make coverage
297
- ```
298
-
299
- The above command executes tests for the ` child-process ` subsystem and
300
- outputs the resulting coverage report.
301
-
302
- Running tests with coverage will create and modify several directories
303
- and files. To clean up afterwards, run:
304
-
305
- ``` text
306
- make coverage-clean
307
- ./configure && make -j4.
308
- ```
239
+ (See the [ running tests] [ ] section of Building guide for more details.)
309
240
310
241
### Step 7: Push
311
242
@@ -661,7 +592,8 @@ If you want to know more about the code review and the landing process, see the
661
592
[ Code of Conduct ] : https://github.com/nodejs/admin/blob/master/CODE_OF_CONDUCT.md
662
593
[ Collaborator Guide ] : ../../../COLLABORATOR_GUIDE.md
663
594
[ guide for writing tests in Node.js ] : ../writing-tests.md
595
+ [ hiding-a-comment ] : https://help.github.com/articles/managing-disruptive-comments/#hiding-a-comment
664
596
[ https://ci.nodejs.org/ ] : https://ci.nodejs.org/
665
597
[ IRC in the #node-dev channel ] : https://webchat.freenode.net?channels=node-dev&uio=d4
666
598
[ Onboarding guide ] : ../../onboarding.md
667
- [ hiding-a-comment ] : https://help.github.com/articles/managing-disruptive-comments/#hiding-a-comment
599
+ [ running tests ] : ../../../BUILDING.md#running-tests
0 commit comments