You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Linux MyPC 5.15.133.1-microsoft-standard-WSL2 #1 SMP Thu Oct 5 21:02:42 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux
Subsystem
No response
What steps will reproduce the bug?
Create a few basic tests
Run them with the command NODE_V8_COVERAGE=./coverage node --test --test-reporter=junit --test-reporter-destination=results.xml --experimental-test-coverage -r ts-node/register test/**/*.spec.ts
How often does it reproduce? Is there a required condition?
100%
What is the expected behavior? Why is that the expected behavior?
@MoLow Are you sure this is a sourcemap issue? I've run into the same thing, and it's fixed by putting an arbitrary import at the top of the file. It seems like the test runner (or coverage collector?) is failing in some way when a module has exports but no imports. Sourcemapping doesn't seem to be involved.
Edit: I've investigated further, and this seems to be file-length related. Adding meaningless comments to the file can make it work/not work. In my testing, I hit upon a 113/114 border: if the file is 113 bytes or fewer, it appears to fail, while 114 bytes or greater seems to succeed. I can make coverage succeed/fail by removing/re-adding a leading newline in the file. Here is a 114 byte file that coverage works for, but removing any single byte will cause it to fail in my testing:
export function sayHello () {
console.log('Hello, Console!');
}
// These chars are here to get to 114 bytesxxxxx
Note there can be no trailing newline and this will work. Removing an x (or any other character) will make it fail.
Replacing one of the final xes with a trailing newline oddly doesn't work -- but replacing it with 2 newlines does, making the minimum size 115 bytes at that point. I do not know what influences the byte-floor.
Version
v20.11.0
Platform
Linux MyPC 5.15.133.1-microsoft-standard-WSL2 #1 SMP Thu Oct 5 21:02:42 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux
Subsystem
No response
What steps will reproduce the bug?
NODE_V8_COVERAGE=./coverage node --test --test-reporter=junit --test-reporter-destination=results.xml --experimental-test-coverage -r ts-node/register test/**/*.spec.ts
How often does it reproduce? Is there a required condition?
100%
What is the expected behavior? Why is that the expected behavior?
Should generate proper coverage
What do you see instead?
content of results.xml:
Additional information
No response
The text was updated successfully, but these errors were encountered: