Repository navigation
Tracking issue: stabilization of test runner code coverage #53924
Description
Activity
- addedfeature requestIssues requesting new Node.js features.Issues requesting new Node.js features.
on Jul 18, 2024 cc @MoLow @atlowChemi @benjamingr if you have other things to add to the list.
Reacted by Moshe Atlow- addedcoverageIssues and PRs related to Node.js code coverage support.Issues and PRs related to Node.js code coverage support.test_runnerIssues and PRs related to the test runner subsystem.Issues and PRs related to the test runner subsystem.
on Jul 18, 2024 - added a commit that references this issue
on Jul 22, 2024 - added a commit that references this issue
on Jul 28, 2024 - added a commit that references this issue
on Aug 5, 2024 - added a commit that references this issue
on Sep 20, 2024 Okay, coverage is now supported via the
run()API.Reacted by Pietro Marchini- added a commit that references this issue
on Oct 4, 2024 @cjihrig You closed this as completed, is code coverage ready to be stablized? We don't have statement coverage yet tho
I am tentatively planning to mark it as stable for v24. There is a performance issue that needs to be investigated more thoroughly, and maybe something related to source maps, but I don't remember off the top of my head.
IMO statement coverage is a nice to have, but realistically I don't foresee it ever being added without some help from V8 because I don't believe we should add the overhead of reparsing all of the code with something like acorn. Plus my understanding is that C8 doesn't do it either, and exactly one person has ever brought it up that I'm aware of.
Plus stable really just means that something can be reliably used and follows semver.
Reacted by Aviv Kellerand maybe something related to source maps
IMHO source maps shouldn't be a priority, it doesn't have to marked stable at the same time, it's still hidden behind
--enable-source-mapsIMO statement coverage is a nice to have, ...
Agreed with everything you said
If you need any help stablizing, LMK. I'll look into some perf (and maybe add some benchmarks if I get a chance).
What is the problem this feature will solve?
This issue is for tracking remaining work to stabilize code coverage in the test runner. When this feature originally shipped, it had documented limitations. Those have all been resolved.
Note that stabilization does not prevent future semver-minor additions or bug fixes.
Here is the minimum list of things that I think need to be resolved:
run()API.lib/internal/test_runner/coverage.jsshould not callparseCommandLine(). The flags should be passed in. This is related to test_runner: do not read fromprocess.argvandprocess.cwd()in run() #53867.--experimental-test-coverageis replaced/aliased with--test-coverageWhat is the feature you are proposing to solve the problem?
Eventually stabilizing test runner code coverage
What alternatives have you considered?
No response