镜像站点 · 本页由第三方 GitHub 只读镜像提供,非 GitHub 官方站点,不接受任何登录或凭据输入。前往 github.com
Skip to content

Tracking issue: stabilization of test runner code coverage #53924

Description

@cjihrig

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:

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

  1. cjihrig commented on Jul 18, 2024

    @cjihrig
    ContributorAuthor

    cc @MoLow @atlowChemi @benjamingr if you have other things to add to the list.

  2. moved this from Awaiting Triage to Triaged in Node.js feature requestson Jul 18, 2024
  3. added
    coverageIssues and PRs related to Node.js code coverage support.
    test_runnerIssues and PRs related to the test runner subsystem.
    on Jul 18, 2024
  4. avivkeller commented on Sep 20, 2024

    @avivkeller
    Member

    Okay, coverage is now supported via the run() API.

  5. avivkeller commented on Oct 28, 2024

    @avivkeller
    Member

    @cjihrig You closed this as completed, is code coverage ready to be stablized? We don't have statement coverage yet tho

  6. cjihrig commented on Oct 28, 2024

    @cjihrig
    ContributorAuthor

    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.

  7. avivkeller commented on Oct 28, 2024

    @avivkeller
    Member

    and 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-maps

    IMO 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).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    coverageIssues and PRs related to Node.js code coverage support.feature requestIssues requesting new Node.js features.test_runnerIssues and PRs related to the test runner subsystem.

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions