Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support test coverage reporters in bun test #3158

Closed
jakeboone02 opened this issue Jun 1, 2023 · 9 comments
Closed

Support test coverage reporters in bun test #3158

jakeboone02 opened this issue Jun 1, 2023 · 9 comments
Labels
bun:test Something related to the `bun test` runner enhancement New feature or request

Comments

@jakeboone02
Copy link
Contributor

What is the problem this feature would solve?

Existing test libraries like Jest and Vitest support coverage reporters like istanbul and c8. bun test merely runs the tests, but it does not collect coverage information that could be provided to a reporter.

What is the feature you are proposing to solve the problem?

Add the ability to specify a reporter (possibly include a default reporter with Bun) and collect coverage information with a --coverage flag or something similar.

What alternatives have you considered?

The only alternative is to stick with Jest/Vitest/etc when coverage reporting is needed.

@jakeboone02 jakeboone02 added the enhancement New feature or request label Jun 1, 2023
@Electroid Electroid added the bun:test Something related to the `bun test` runner label Jun 1, 2023
@TiBianMod
Copy link

+1

@Jarred-Sumner
Copy link
Collaborator

Bun v0.7.3 now includes a default code coverage reporter.

To use it:

bun test --coverage

It will output something like:

-------------|---------|---------|-------------------
File         | % Funcs | % Lines | Uncovered Line #s
-------------|---------|---------|-------------------
All files    |   38.89 |   42.11 |
 index-0.ts  |   33.33 |   36.84 | 10-15,19-24
 index-1.ts  |   33.33 |   36.84 | 10-15,19-24
 index-10.ts |   33.33 |   36.84 | 10-15,19-24
 index-2.ts  |   33.33 |   36.84 | 10-15,19-24
 index-3.ts  |   33.33 |   36.84 | 10-15,19-24
 index-4.ts  |   33.33 |   36.84 | 10-15,19-24
 index-5.ts  |   33.33 |   36.84 | 10-15,19-24
 index-6.ts  |   33.33 |   36.84 | 10-15,19-24
 index-7.ts  |   33.33 |   36.84 | 10-15,19-24
 index-8.ts  |   33.33 |   36.84 | 10-15,19-24
 index-9.ts  |   33.33 |   36.84 | 10-15,19-24
 index.ts    |  100.00 |  100.00 |
-------------|---------|---------|-------------------

@ImLunaHey
Copy link
Contributor

@Jarred-Sumner is there an issue we can follow for support for html, json, etc. reporters for that?

@Jarred-Sumner
Copy link
Collaborator

@ImLunaHey there is an issue for lcov #4015 which could be used to generate an HTML reporter. But feel free to file one for HTML specifically

@ctsstc
Copy link

ctsstc commented Dec 28, 2023

Uncovered Lines is nice to figure things out, but other things like logical branching is not explicitly visible in this report. Sure your % Funcs or %Lines may be down, but there's not much to go off of regarding this. I know Jest doesn't expose this in the CLI much either, but I normally end up opening up an HTML report for this kind of visibility.

Example

Note the: src/utilities/files.ts with no uncovered line numbers, but funcs and lines are not fully covered. This does not make it easy to determine what still needs additional coverage, which I assume the line is tested, but a logical branch within that line is likely not tested.

image

@pukingrainbows
Copy link

pukingrainbows commented May 22, 2024

(noobie question) Meanwhile we wait for properly report support, I was trying to to consume outup from the cli after running test --coverage but for some reason running

	const proc = spawn(["bun", "test"], { stdout: "pipe" });
	const output = await new Response(proc.stdout).text();

output it is empty, does anyone know how can I get the coverage output text?

ps. I have configured that --coverage it is always enable

@jakeboone02
Copy link
Contributor Author

@pukingrainbows try stderr instead of stdout

@pukingrainbows
Copy link

@pukingrainbows try stderr instead of stdout

ohhh that worked, why was that? shouldn't be part of stdout?

@jakeboone02
Copy link
Contributor Author

ohhh that worked, why was that? shouldn't be part of stdout?

I'm not really sure. I only know because of this comment from Jarred on one of my PRs: #2566 (review).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bun:test Something related to the `bun test` runner enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

7 participants