-
-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
Coverage: give the choice between c8 and nyc #1252
Comments
+1 for this. I really like the idea of using In addition to all issues mentioned by @tqn-treezor, I have problems when testing codebase with multiple testing tools. I have a component library which is tested by using Having an option for choosing between |
+1 |
I think all described points are true only because Jest has configured |
I get your point. Still, as mentioned above, since Just for the record, I'm also running into issues where Running coverage on a single test file: ---------------------|---------|----------|---------|---------|-------------------------------------
File | % Stmts | % Branch | % Funcs | % Lines | Uncovered Line #s
---------------------|---------|----------|---------|---------|-------------------------------------
strategy.ts | 99.13 | 100 | 100 | 99.13 | 57-58 Running coverage on all test files: ---------------------|---------|----------|---------|---------|-------------------------------------
File | % Stmts | % Branch | % Funcs | % Lines | Uncovered Line #s
---------------------|---------|----------|---------|---------|-------------------------------------
strategy.ts | 36.36 | 100 | 52.94 | 36.36 | ...,161-187,195-207,215-220,227-230 This did not happen using Jest and |
It does not happen in Jest because it is configured by Jest. What is the difference between us configuring v8 and nyc? One is already configured but not correctly, it seems. But at least it is already an integral part of Vitest, that we can improve. |
I got same problem ,and in Vitest React Testing Lib Example coverage is incorrect。 |
|
I'm not expert here so please correct me if there's something misunderstood. So, mostly thinking out loud: Difference between v8 report and any other AST based instrumented code coverage (like The v8 coverage report includes every single line. I'm happy to help with this issue but quite unsure where to start from, if |
I think it is a good idea to support I'm not sure whether we need an option to switch between |
I guess the best solution might be we decouple the coverage logic, and make a provider interface for c8 and nyc to make them interchangeable. I currently don't have enough bandwidth to work on it, counting on someone interested in giving it a try. |
I definitely think we should create a common interface that can be implemented by different coverage libraries, but I am not sure its possible to run c8 with browser? I wouldn’t want people to have different coverage reports depending on the environment. Maybe we can disable c8 coverage, if user enables |
I'm also having this same issue, I tried switching to node v16.14.0 (I was using 16.13.0) and I still got an empty coverage report |
Edit: I'm not too familiar with coverage tools so I had the impression c8 was cli/node based tool while nyc was somehow brower based (given it's usually used with mocha, e.g. mocha-vite-puppeteer). Sorry for my confusion here, I was trying to find good information on nyc to chip in. |
Exactly as @bjarkihall mentioned here, Coverage logic decoupled, actions depending on which coverage tool is chosen by user:
I think the integration itself will be on istanbul rather than When I did some testing with |
Clear and concise description of the problem
I observed huge coverage gaps when transitioning from Jest to Vitest, the reason coming from C8 not ignoring a few things:
types.ts
were ignored by default in Jest and not in Vitest*.entity.ts
were ignored by default in Jest and not in Vitest*.test.ts
were ignored by default in Jest and not in VitestThe "deep reason" seems that Jest uses nyc, and Vitest uses c8, and they don't have the same way of running through the code to make the coverage report.
Besides, the way c8 does it (not ignoring comments) seems objectively wrong, because adding comments in any covered branch in any file will actually increase the code coverage when it really shouldn't. Same for multiple line objects.
Suggested solution
Give the choice to use nyc instead of c8.
Alternative
Fix c8? There is actually an issue dating from 2019 talking about the comments counted as covered here: bcoe/c8#182
Additional context
No response
Validations
The text was updated successfully, but these errors were encountered: