Repository navigation
Tracking issue: stabilization of test runner code coverage #53924
Description
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:
- Coverage should be supported via the
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-coverage
What is the feature you are proposing to solve the problem?
Eventually stabilizing test runner code coverage
What alternatives have you considered?
No response
Activity
cjihrig commentedon Jul 18, 2024
cc @MoLow @atlowChemi @benjamingr if you have other things to add to the list.
test_runner: refactor coverage to pass in config options
test_runner: refactor coverage to pass in config options
test_runner: refactor coverage to pass in config options
test_runner: add support for coverage via run()
avivkeller commentedon Sep 20, 2024
Okay, coverage is now supported via the
run()API.test_runner: add support for coverage via run()
avivkeller commentedon Oct 28, 2024
@cjihrig You closed this as completed, is code coverage ready to be stablized? We don't have statement coverage yet tho
cjihrig commentedon Oct 28, 2024
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.
avivkeller commentedon Oct 28, 2024
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-mapsAgreed 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).