Test Coverage API

[connor4312]

📣 2024-03 update: test coverage support has been finalized. You can find the finished, usable version of the API in vscode.d.ts and a guide in our docs.

Original discussion has been preserved below.

---

Notes researching of existing formats:

## Clover - Contains timestamp and total lines of code, files, classes, coverage numbers (see below) - Also _can_ include complexity information - Lines are covered as XML simply `` - Conditionals are represented as ``. Either truecount/falsecount being 0 indicates incomplete branch coverage. > Clover uses these measurements to produce a Total Coverage Percentage for each class, file, package and for the project as a whole. The Total Coverage Percentage allows entities to be ranked in reports. The Total Coverage Percentage (TPC) is calculated as follows: > ``` > TPC = (BT + BF + SC + MC)/(2*B + S + M) * 100% > > where > > BT - branches that evaluated to "true" at least once > BF - branches that evaluated to "false" at least once > SC - statements covered > MC - methods entered > > B - total number of branches > S - total number of statements > M - total number of methods > ``` ## gcov Format info on the bottom of: http://ltp.sourceforge.net/coverage/lcov/geninfo.1.php - Organized per test, which are associated with one or more files. Indicates functions and how many times each function was called. - Lines have number of times they were hit, `DA:,[,]` - Has similar branch coverage, but has indexed branches instead of true/false. A branch with 0 taken is uncovered. - `BRDA:,,,`, declared multiple times for line, one for each branch - No timestamp ## cobertura - General coverage information/count - Number of times each line was hit. - Has conditions in a slightly less-strict way, `` - Normal lines look like `` - Has timestamp and metadata - Has method call count (everything is organized in classes)

This results in the following API. The TestCoverageProvider is given as an optional provider on the managed TestRun object. This is similar to the SourceControl interface in vscode.d.ts. The provider is then pretty standard; it'll only be examined when the run finishes, so all its data is static.

It has a method to get general coverage information for all files involved in the run, and a method to provide detailed coverage for a URI.

I refer to the atomic unit of coverage as "statement coverage". The examined test formats only provide line-based coverage, but statement coverage is what these are actually trying convey approximate and most tooling (e.g. istanbul/nyc) is technically capable of per-statement rather than per-line coverage. Therefore, it's called statement coverage, but it can be used as line coverage.

The API is physically large due to the nature of data being provided, but is conceptually pretty simple (at least compared to the Test Controller API!). I don't like the method names on the TestCoverageProvider, but have not thought of better ones yet.

declare module 'vscode' {

    // https://github.com/microsoft/vscode/issues/123713

    export interface TestRun {
        /**
         * Test coverage provider for this result. An extension can defer setting
         * this until after a run is complete and coverage is available.
         */
        coverageProvider?: TestCoverageProvider;
        // ...
    }

    /**
     * Provides information about test coverage for a test result.
     * Methods on the provider will not be called until the test run is complete
     */
    export interface TestCoverageProvider<T extends FileCoverage = FileCoverage> {
        /**
         * Returns coverage information for all files involved in the test run.
         * @param token A cancellation token.
         * @return Coverage metadata for all files involved in the test.
         */
        // @API - pass something into the provide method:
        // (1) have TestController#coverageProvider: TestCoverageProvider
        // (2) pass TestRun into this method
        provideFileCoverage(token: CancellationToken): ProviderResult<T[]>;

        /**
         * Give a FileCoverage to fill in more data, namely {@link FileCoverage.detailedCoverage}.
         * The editor will only resolve a FileCoverage once, and only if detailedCoverage
         * is undefined.
         *
         * @param coverage A coverage object obtained from {@link provideFileCoverage}
         * @param token A cancellation token.
         * @return The resolved file coverage, or a thenable that resolves to one. It
         * is OK to return the given `coverage`. When no result is returned, the
         * given `coverage` will be used.
         */
        resolveFileCoverage?(coverage: T, token: CancellationToken): ProviderResult<T>;
    }

    /**
     * A class that contains information about a covered resource. A count can
     * be give for lines, branches, and functions in a file.
     */
    export class CoveredCount {
        /**
         * Number of items covered in the file.
         */
        covered: number;
        /**
         * Total number of covered items in the file.
         */
        total: number;

        /**
         * @param covered Value for {@link CovereredCount.covered}
         * @param total Value for {@link CovereredCount.total}
         */
        constructor(covered: number, total: number);
    }

    /**
     * Contains coverage metadata for a file.
     */
    export class FileCoverage {
        /**
         * File URI.
         */
        readonly uri: Uri;

        /**
         * Statement coverage information. If the reporter does not provide statement
         * coverage information, this can instead be used to represent line coverage.
         */
        statementCoverage: CoveredCount;

        /**
         * Branch coverage information.
         */
        branchCoverage?: CoveredCount;

        /**
         * Function coverage information.
         */
        functionCoverage?: CoveredCount;

        /**
         * Detailed, per-statement coverage. If this is undefined, the editor will
         * call {@link TestCoverageProvider.resolveFileCoverage} when necessary.
         */
        detailedCoverage?: DetailedCoverage[];

        /**
         * Creates a {@link FileCoverage} instance with counts filled in from
         * the coverage details.
         * @param uri Covered file URI
         * @param detailed Detailed coverage information
         */
        static fromDetails(uri: Uri, details: readonly DetailedCoverage[]): FileCoverage;

        /**
         * @param uri Covered file URI
         * @param statementCoverage Statement coverage information. If the reporter
         * does not provide statement coverage information, this can instead be
         * used to represent line coverage.
         * @param branchCoverage Branch coverage information
         * @param functionCoverage Function coverage information
         */
        constructor(
            uri: Uri,
            statementCoverage: CoveredCount,
            branchCoverage?: CoveredCount,
            functionCoverage?: CoveredCount,
        );
    }

    // @API are StatementCoverage and BranchCoverage etc really needed
    // or is a generic type with a kind-property enough

    /**
     * Contains coverage information for a single statement or line.
     */
    export class StatementCoverage {
        /**
         * The number of times this statement was executed, or a boolean indicating
         * whether it was executed if the exact count is unknown. If zero or false,
         * the statement will be marked as un-covered.
         */
        executed: number | boolean;

        /**
         * Statement location.
         */
        location: Position | Range;

        /**
         * Coverage from branches of this line or statement. If it's not a
         * conditional, this will be empty.
         */
        branches: BranchCoverage[];

        /**
         * @param location The statement position.
         * @param executed The number of times this statement was executed, or a
         * boolean indicating  whether it was executed if the exact count is
         * unknown. If zero or false, the statement will be marked as un-covered.
         * @param branches Coverage from branches of this line.  If it's not a
         * conditional, this should be omitted.
         */
        constructor(executed: number | boolean, location: Position | Range, branches?: BranchCoverage[]);
    }

    /**
     * Contains coverage information for a branch of a {@link StatementCoverage}.
     */
    export class BranchCoverage {
        /**
         * The number of times this branch was executed, or a boolean indicating
         * whether it was executed if the exact count is unknown. If zero or false,
         * the branch will be marked as un-covered.
         */
        executed: number | boolean;

        /**
         * Branch location.
         */
        location?: Position | Range;

        /**
         * Label for the branch, used in the context of "the ${label} branch was
         * not taken," for example.
         */
        label?: string;

        /**
         * @param executed The number of times this branch was executed, or a
         * boolean indicating  whether it was executed if the exact count is
         * unknown. If zero or false, the branch will be marked as un-covered.
         * @param location The branch position.
         */
        constructor(executed: number | boolean, location?: Position | Range, label?: string);
    }

    /**
     * Contains coverage information for a function or method.
     */
    export class FunctionCoverage {
        /**
         * Name of the function or method.
         */
        name: string;

        /**
         * The number of times this function was executed, or a boolean indicating
         * whether it was executed if the exact count is unknown. If zero or false,
         * the function will be marked as un-covered.
         */
        executed: number | boolean;

        /**
         * Function location.
         */
        location: Position | Range;

        /**
         * @param executed The number of times this function was executed, or a
         * boolean indicating  whether it was executed if the exact count is
         * unknown. If zero or false, the function will be marked as un-covered.
         * @param location The function position.
         */
        constructor(name: string, executed: number | boolean, location: Position | Range);
    }

    export type DetailedCoverage = StatementCoverage | FunctionCoverage;

}

[connorshea]

Would it be possible to load the coverage data directly from a file on disk (or in the remote workspace, whatever we want to call it) rather than as a result of the output of the test run? It seems like it'd be pretty limiting to only have coverage if it were provided by a test runner extension, if I'm understanding your current API draft correctly.

In my codebase for work, the test suite takes well over 90 minutes to run in full. So it pretty much only gets run in CI (parallelized, obviously), which means that the coverage is only available as a CI artifact. It never exists locally (at least, not from a full run).

The more likely case where this might be useful would be if you ran your test suite locally (because it was fast enough), but not using a VS Code Test Explorer extension. So then you just had the coverage.xml (or whatever file/format your test framework outputs) on your machine, and VS Code would either know to look for that, or could be told to go into coverage mode using the data inside it.

[connor4312]

Would it be possible to load the coverage data directly from a file on disk (or in the remote workspace, whatever we want to call it) rather than as a result of the output of the test run? It seems like it'd be pretty limiting to only have coverage if it were provided by a test runner extension, if I'm understanding your current API draft correctly.

Yes, the APIs are designed for this 🙂 You can call createTestRun at any time, so you could do that when you load the file (passing in persist as false since VS Code does not need to remember the already-externally-stored results), parse them, then immediately .end() the run.

[connor4312]

also: I'm pretty interested in getting the CI story right, so I'm glad to have someone who has an existing use case and need for it! Please let me know if this or any other parts are confusing or seem to present roadblocks for you.

[connorshea]

I'd make sure to document the coverage-from-file use-case specifically (I know this is an API draft and actual docs are a while away, but I think it's important 😄).

Regarding CI, probably a crazy idea, but:

It'd be nice to point VS Code at a URL where it can get the coverage file (maybe it passes a param with the current branch name as well) so I wouldn't have to download the coverage.xml myself manually. But that'd have to be custom-built to redirect to the latest CI artifacts somehow since there's no stable URL that CircleCI (or any other CI system) provides for something like this, as far as I know.

And maybe that should be a capability handled by an extension rather than as something in core VS Code. 🤷‍♂️

[connor4312]

Yep, that's a good idea for an extension

[ashgti]

I have a question about the FileCoverage API. If I am looking at a coverage report, it looks like I only know the file URI. So, if someone starts a coverage test run (which may take a while to run) then makes any changes to the file the statements may not line up correctly with the current editor.

In the TextDocument API there is a version field that tracks revisions to a specific TextDocument.

Should we track FileCoverage to the specific version of the file the test run was started with? Maybe as an optional param?

[connor4312]

While we could store the version, there's not a lot of useful things we can do with it (and it gets reset if the file is opened and closed). The most reliable way to do this would be for the extension to use registerFileSystemProvider to create a custom uri scheme/readonly filesystem from which it can serve the version of the file that was used for the coverage run.

[jdneo]

The field executionCount in *Coverage classes shows the excution information, what about the missed part.

For example, a method or a line might have 4 branches, but only 2 of them are executed.

Take the Jacoco in Java as an example, the coverage will contains such information:

In editor each line can also have this metadata

---

Update

forget about it, I just realized, if the executionCount is zero, then it's uncovered.

[JustinGrote]

For reference, there is an updated API with migration guide that was posted: https://github.com/microsoft/vscode/issues/122208#issuecomment-865391103

[connor4312]

I implement the coverage API and data flow for it internally. There's no UI for it, but it's there to try out. At some point in the next few weeks UI will magically show up ✨

[JustinGrote]

@connor4312 will the AutoRun have an option to re-run tests if lines under their coverage are edited in the file, or will we need to provide our own implementation of that?

[connor4312]

Autorun will be primarily extension-controlled

[JustinGrote]

Sounds good, was thinking of basically implementing it this way (as a configurable option):

1. If coverage is found, start a filewatcher on the covered files.
2. If OnDocumentChanged, find tests that match the covered changed lines and do a run profile on them on save.

[ashgti]

Should the coverage be a boolean flag on the TestRunRequest or should it be an entirely different profile?

In my existing Test Profiles I'm using the configureHandler to let users enable coverage reporting (handled by my own extension until this API is stabilized) with the Run or Debug profiles. But if I made a distinct profile for Coverage, would that mean I'd need to register two versions of it (one for Run + Coverage and a second one for Debug + Coverage)?

[connor4312]

In this model we assume run-with-coverage and debugging are disjoint. This is the same as what IntelliJ and Visual Studio do by default, and in some runtimes (e.g. nyc in its default instrumented mode) debugging coverage is not possible at all.

[gjsjohnmurray]

I implement the coverage API and data flow for it internally. There's no UI for it, but it's there to try out. At some point in the next few weeks UI will magically show up ✨

@connor4312 what is the current status of UI for the coverage API? I'm not seeing any when I run test-provider-sample even though it seems to implement coverage.

[shanewazabbas]

My wish is this new UI doesn't affect existing workflow. Like adding breakpoints beside line numbers. Or mask squiggly lines intellisense code issues.

Also hoping it can work well for lcov and pytest cases. Since one problem there is the coverage report path argument can't be dynamically changed based on which test are actually being ran.

[gjsjohnmurray]

@connor4312 what is the current status of UI for the coverage API? I'm not seeing any when I run test-provider-sample even though it seems to implement coverage.

A quick ping to see if there's any sign of this coming down the pike...

[connor4312]

It's coming, but still a couple iterations out; my time is currently used by a new thing that'll be announced soon.

[JustinGrote]

@connor4312 all your great efforts are appreciated, we look forward to it!

[ioquatix]

I implemented support for the proposed coverage interface, and I have coverage, but I don't seem to see it in the UI. What am I doing wrong?

[gjsjohnmurray]

@ioquatix you're not doing anything wrong. Coverage isn't yet surfaced in the UI. I think this is still on @connor4312's todo list.

[ioquatix]

It would be pretty neat if we could attach coverage to test items, so that when those lines are changed, the test items are automatically re-run. I guess we can do this by hand but it seems a little tricky.

[eggyal]

@ioquatix: better if that would be by range rather than by line (some coverage regions span only part of a line, some span many lines).

[nickzhums]

From Visual Studio Code Java team, we have been facing increasing demand for testing coverage. From January 2023 survey feedback, 5 out of 6 verbatims related to testing have mentioned coverage.

It seems this feature is particulary important to java developers and they take this as part of the complete experience for testing, so updates to the API would be greatly appreciated, thank you :)

[worksofliam]

Hi! I am also looking to get this API merged in sooner than later. I'm about to overhaul a code-coverage extension I wrote for IBM i (COBOL, C, RPG) and I can see the testing namespace does not yet really support coverage tests.

[gjsjohnmurray]

@connor4312 is there any prospect that the UI for test coverage will "magically show up ✨" soon?

[kozlovvski]

@connor4312 any progress on this? 👀

[connor4312]

Some will be made in this November iteration

[connor4312]

UI mockup:

• The test result in the Test Results view has a tree item that indicates a coverage summary. Clicking on it opens coverage for that run. This causes two things to happen:
  • Coverage decorations for files included in the coverage report are added to editors.
  • A Test Coverage view is open that shows a tree of files with coverage information. These may or may not map to physical files on disk, so e.g. augmenting the explorer is not (always) appropriate
• I had this idea for the view inspired by xcode's coverage view. I didn't want to go IntelliJ's direction with a massive, dense table.
  • Small, color-coded bars indicate rough coverage for each type, and hovers show the exact numbers. Users can sort items in the tree by % of each type of coverage. Bars are only show for each type of coverage a test extension emits. If it only emitted statement coverage, only one bar is shown.
  • For an extension that provides more than just one type of coverage, I plan to use Clover's total coverage formula to show the "total coverage %" by default beside the indicator bars, but users can configure what number is displayed there, as a view action.
• The close icon in the view closes the report, removing the view and editor decorations.

Followup from team discussion:

• Steven Clark shared a study he did some time ago indicating that statement coverage was not a useful driver of logical coverage. However, data and my own experience indicate branch coverage is more useful. Let's weight it higher in the "total coverage" formula.
• Some concern about view proliferation. Perhaps we have an option to show coverage in the explorer view instead of a separate view.
• I want to investigate how to deal with decorations for code that's change since the test was run. Can we use local history to compute how decorations should be moved?
• Can we associate tests with a covered region to allow running tests that affect given code?

[worksofliam]

@connor4312

Some concern about view proliferation. Perhaps we have an option to show coverage in the explorer view instead of a separate view.

Please consider how we can provide results in our own views also. I'd really like to set coverage results for a Uri and then any tree view that has a TreeNode with the resourceUri which matches the coverage result, it would show the UI for that TreeNode item.

This similar to how DiagnosticCollection works. If I set diagnostics based on Uri, then in any view where I references the Uri in the resourceUri property, then the number + color shown on my TreeItem label will be based on the diagnostic collection (if there are warnings it's yellow, if errors it's red, etc). Perhaps even being able to lock it down to resourceUri and the view context would be good too.

The reason I ask for this is because I'd like to not only expose the coverage data in the explorer (which I absolutely will be doing), but also in my own trees where I show data from a coverage services running on another platform.

Nonetheless, your mock looks awesome. I'm so ready to start exposing my coverage data in a more VS Code native fashion.

[ioquatix]

I'd like to update my plugin to report coverage, how can we try this out?

[dlschmidt]

Can we associate tests with a covered region to allow running tests that affect given code?

That should be possible, as every coverage region was at some point executed by atleast one test, which will result in the neccessary relation. I think the Live Unit Testing feature in Visual Studio works very similar to this. Will be interesting later which coverage providers collect such data or discard it. Still, would be really helpful to have some API to set such relations in order to have similar features like Live Unit Testing or to hover over coverage regions and get a list of succeeding/failing tests like in VS.

I really appreciate the work on the code coverage feature, as I am eagerly waiting for this for a long time. ProgressBar-like style looks very reasonable for a quick overview compared to a number with 1% precision as in IntelliJ.

EDIT:

Some concern about view proliferation. Perhaps we have an option to show coverage in the explorer view instead of a separate view.

Also +1 for the idea to show the coverage data in the explorer view. Maybe one could add a button to toggle between the coverage results and warning/error badges as needed. This could even be extended to regular test results. So there really would be some potential.

[Trass3r]

* I had this idea for the view inspired by [xcode's coverage view](https://developer.apple.com/library/archive/documentation/DeveloperTools/Conceptual/testing_with_xcode/Art/twx-codedov-4_2x.png). I didn't want to go [IntelliJ's direction](https://resources.jetbrains.com/help/img/idea/2023.2/coverage-report-overview.png) with a massive, dense table.

👍🏽 Will the tree be expandable down to functions like in the screenshot?

And I assume when you double-click an item it opens the file and shows line coverage?

[connor4312]

I'd really like to set coverage results for a Uri and then any tree view that has a TreeNode with the resourceUri which matches the coverage result, it would show the UI for that TreeNode item.

My concern here is that the bars are very big and on tree items with inline actions could end up overflowing or occluding the contents of the container. This may be something we do, and would be configurable, will have to explore.

I'd like to update my plugin to report coverage, how can we try this out?

Check this out: https://code.visualstudio.com/api/advanced-topics/using-proposed-api The UI isn't in VS Code yet, but it will be soon. Also, please provide feedback whether the APIs work or don't work for you!

Will the tree be expandable down to functions like in the screenshot?

I want that, but it potentially needs an API tweak. Currently we may not know know whether a file has function coverage until we resolveFileCoverage, and if there's no function coverage at that point we may end up looking silly (unless we have other information we can always show there, maybe granular coverage info?)

[jdneo]

Hi @connor4312,

I tried the coverage api with the help of the extension sample (test-provider-sample), and have a question:

In the sample extension, looks like it does not use the TestRunProfileKind.Coverage profile. After running the tests, user needs to click the button in the TEST RESULTS view to see the coverage status.

Why not using TestRunProfileKind.Coverage?

I tried to create a TestRunProfileKind.Coverage profile, but didn't see the shortcut appear in the test explorer, neither the context menu of the items in the text explorer. Is it by design or I missed anything?

I thought that if the user runs the test with the coverage profile, the coverage explorer should automatically appear.

[connor4312]

After running the tests, user needs to click the button in the TEST RESULTS view to see the coverage status.

In the latest Insiders, coverage is automatically opened when an extension finishes a test run that includes coverage.

Why not using TestRunProfileKind.Coverage?

I will add this 👍 that kind is pretty much unused right now, but making sure that works fluidly is something I'll do before release.

For general edification, the month of December is our housekeeping iteration, and then we resume feature development in Jan. My goal is for coverage to be feature-complete in January and get our team self-hosting on it for VS Code development, and then finalize the API for the February 2024 release. Depending where we are, coverage could be finalized in January instead, but I don't anticipate this.

[jdneo]

Some questions and feedbacks:

About the FunctionCoverage

Currently, after feeding the function coverage to VS Code, the coverage view will show the function coverage ratio for each file. Looks like currently the UI will not reflect the information about the name and location fields of the function coverage. Will they be used in the future?

About the three coverage bars.

Just my personal feeling. Currently the number of the coverage bars displayed in the coverage view are different across different files. It depends on

• How many kinds of the coverage are supported by the provider.
• The content of the file. For example, the code may not have branches, so it won't have the branch coverage.

As a user, he may not be able to get the ratio of each kind of coverage with a quick glance. Sometimes he may need to hover onto those coverage bars to get which kind it is. Seems a little bit inconvenient.

[connor4312]

Looks like currently the UI will not reflect the information about the name and location fields of the function coverage. Will they be used in the future?

Yes, they will

Sometimes he may need to hover onto those coverage bars to get which kind it is. Seems a little bit inconvenient.

I think the thing to do here is to report a CoveredCount of 0 covered / 0 total for each kind you want to report, if there's no other information available.

Currently those will show green as 100% covered, but I think I'll change it so that they're muted.

[jdneo]

I noticed the latest Insider will not show the coverage information in the File Explorer, will we have any kind of decorator/description hint for the file entry in the file explorer in the future?

In my point of view, the coverage support and source control support have a lot of similarity about UI component. In VS Code, it provides two ways to provide information about source control status.

1. The first way is the straightforward way that user can quickly get the information.
   1. In editor, the gutter decorator tells which parts are changed.
   2. In File explorer, the file decorator tells which files are changed.
2. The second way is a dedicated view to provide detailed information to users: The Source Control view shows all the details for all the changed files.

I think the same concept can be applied to coverage as well:

1. straightforward UI hints: editor gutter decorator, file decorator in file explorer
2. A dedicated coverage view to provide detailed in formation.

About the current coverage view, I have one more input about the presentation. I understand that the table view makes people feel complex and heavy, which may not apply to VS code's product philosophy. However, the advantage of table is that user can get an accurate coverage number quickly. While for the progress bar, User cannot tell that until hovering the mouse onto it.

You can imagine this case: a project requires the coverage to reach 70%. both 69% and 71% looks similar when it's a progress bar, user have to hover the mouse onto it to tell the difference. This is another reason that a summary hint besides the file item in file explorer is helpful. Take IDEA as an example:

[connor4312]

The latest Insiders does have test coverage information in the explorer, following https://github.com/microsoft/vscode/pull/198891, which will be visible if coverage locations match the URIs of files in the workspace.

straightforward UI hints: editor gutter decorator, file decorator in file explorer

will come in Jan 👍

However, the advantage of table is that user can get an accurate coverage number quickly. While for the progress bar, User cannot tell that until hovering the mouse onto it.... You can imagine this case: a project requires the coverage to reach 70%. both 69% and 71% looks similar when it's a progress bar, user have to hover the mouse onto it to tell the difference.

I'm curious how often a user would care about e.g. a 69% coverage versus a 70% coverage. Would that be pretty much exclusively for reaching a number for acceptance? If so, would allowing the user to customize when the bar is red/yellow/green accomplish the same goal? I.e. if I set my yellow at 70%, then as long as I run coverage and don't see any red then I know at a glance I'm okay.

[jdneo]

Would that be pretty much exclusively for reaching a number for acceptance?

Yes, in Java, the Jacoco Maven plugin can set the coverage ratio. Below is an example which requires an overall instruction coverage of 80% and no class must be missed:

<rules>
  <rule>
    <element>BUNDLE</element>
    <limits>
      <limit>
        <counter>INSTRUCTION</counter>
        <value>COVEREDRATIO</value>
        <minimum>0.80</minimum>
      </limit>
      <limit>
        <counter>CLASS</counter>
        <value>MISSEDCOUNT</value>
        <maximum>0</maximum>
      </limit>
    </limits>
  </rule>
</rules>

If so, would allowing the user to customize when the bar is red/yellow/green accomplish the same goal?

This can be a solution, I guess. I'm ok to wait for more users feedback. At least there is a solution now.

[ioquatix]

Okay, I managed to get it working.. sort of. I definitely don't have 100% coverage on every file... probably a bug in my code.

[ioquatix]

Ah, this is looking better/more accurate:

[ioquatix]

Are we planning to add code coverage to the editor/code view as well? It would be useful to know what lines are not executed.

[connor4312]

Are we planning to add code coverage to the editor/code view as well? It would be useful to know what lines are not executed.

Yes, that will happen next month, after the holidays

[fhnaseer]

I believe that this % is lines covered. MS code coverage file (.coverage) contains Lines Covered, Lines Partially Coveredand Lines Not Covered. I wonder how this kind of information can be displayed. Maybe like [70%-20%-10%] or some other way.

Ah, this is looking better/more accurate:

[JustinGrote]

I believe that this % is lines covered. MS code coverage file (.coverage) contains Lines Covered, Lines Partially Coveredand Lines Not Covered. I wonder how this kind of information can be displayed. Maybe like [70%-20%-10%] or some other way.

I am of the opinion your extension could go by token rather than by line in that case and generate a more accurate entry, I don't see the need to clutter this unnecessarily with a stratified coverage.

[ioquatix]

For the most part I encourage people to aim for 100% coverage so the main goals would be:

1. Identify files without 100% coverage easily.
2. Provide feedback in the editor about the missing coverage so they can write appropriate tests.

Showing 90% (statement|branch|whatever) coverage of file x isn’t as important IMHO as simply pointing out that coverage is missing.

[jdneo]

@connor4312

I noticed that VS Code now can display the profile for coverage kind, is this heart icon just a placeholder? 😂

I noticed that codicon already has an icon named debug-coverage