-
-
Notifications
You must be signed in to change notification settings - Fork 6.5k
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
[Bug]: Node 20.10.0 V8 coverage incorrect when file tested by multiple test files #14764
Comments
This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 30 days. |
This issue was closed because it has been stalled for 30 days with no activity. Please open a new issue if the issue is still relevant, linking to this one. |
1 similar comment
This issue was closed because it has been stalled for 30 days with no activity. Please open a new issue if the issue is still relevant, linking to this one. |
This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
Version
29.7.0
Steps to reproduce
Line 4-5 are marked as uncovered, although this is covered in test2.spec.ts
Expected behavior
100% code coverage. Code coverage when run from multiple test files is the same as if code is tested in a single test file.
Actual behavior
Code covered by tests in test2.spec.ts is not recognized as covered
Additional context
This issue started to appear on node 20.10.0. Node 20.9.0 runs correctly. I've also tested the jest 30 alpha2 version and the result is the same. I think this might be actually more of a nodejs bug than a jest issue. But I don't really know what happens between jest reporting the coverage and v8 reporting numbers for the lines.
I became aware of this issue because our CI delivered different coverage numbers than we saw locally. I isolated the issue down to being caused by the maxWorkers=2 setting we use in CI. We get different results locally as well, when running with runInBand or just 2 workers. It seemed like the order of execution is relevant for the coverage.
The code example is extracted from one file which reported different numbers based in the worker count and simplified slightly.
Sorry for editing this issue multiple times. I've not provided correct reproduction steps
Environment
The text was updated successfully, but these errors were encountered: