-
-
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
fix: collect coverage from vm script #13962
Conversation
The CI is failing because it's adding coverage on |
|
I see, thanks for the explanation. |
Yeah, that sounds reasonable! Might give false positives if file is also pulled in by jest itself, but probably edge casey enough |
Seems ci is not totally happy |
I made the change that we agreed on. The CI should be good now. Please let me know if there's anything else. |
return this._v8CoverageResult | ||
.filter(res => res.url.startsWith('file://')) | ||
.map(res => ({...res, url: fileURLToPath(res.url)})) | ||
.filter( | ||
res => | ||
// TODO: will this work on windows? It might be better if `shouldInstrument` deals with it anyways | ||
res.url.startsWith(this._config.rootDir) && | ||
this._v8CoverageSources!.has(res.url) && | ||
matchesCoveragePattern(res.url) && | ||
shouldInstrument(res.url, this._coverageOptions, this._config), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
hmmm, thinking about it - shouldn't this option be enough? and the fact the css transform is included is because we are missing an ignore pattern in our test?
(sorry about the back and forth 🙈)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No worries at all. I'm really not familiar with the code base or v8 so I don't fully understand what's going on.
I was simply following the instructions from someone who answered my question on StackOverflow.
I blamed the file and I see that _v8CoverageSources
was introduced as a substitute to _fileTransforms
in #12912 to avoid losing the list of files when calling jest.resetModules()
.
However, I don't see why we would need this in the filter. The 2 other checks should be enough:
res.url.startsWith(this._config.rootDir) && shouldInstrument(...);
This is why this PR was removing it: #10657
So if you agree, I will
- remove this line
- exclude
cssTransform.js
in the other test withcoveragePathIgnorePatterns
so that it doesn't appear in the coverage.
Could you confirm this is the correct way?
Edit: The problem is if I do that, then this line here may break and I don't know where I could get the transformedFile
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For me it looks right if by default only files explicitly imported in tests are included in the coverage report. For example, that’s the default of c8
. They have all
, include
, exclude
option to include other files.
So it made sense that collectCoverageFrom
option is collecting coverage from not only imported files. Current Jest documentation of the option agrees: "If a file matches the specified glob pattern, coverage information will be collected for it even if no tests exist for this file and it's never required in the test suite."
If I didn't miss some detail.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So maybe if I can't find the file in _v8CoverageSource, I can call transformFile()
on it and add it to the map. Would that be ok?
... or it's ok to have codeTransformResult = undefined
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure what you have in mind. I was trying to say that not including cssTransform.js
in coverage report by default seems to be expected behaviour.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@mrazauskas so do you mean we shouldn't touch that part of the code and find another way to add the files loaded with vm.runInContext
to _v8CoverageSources
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let’s wait for Simen’s feedback. He was commenting that cssTransform.js
could get included or not because of ignore pattern. I try to suggest that by default only explicitly imported files should be included in the report and collectCoverageFrom
option could be used to override that. This is what your current implementation does. If I got it right.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My thought was that shouldInstrument
should return the right thing - if a file shouldn't get instrumented, it shouldn't be include in a coverage report
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@SimenB you're right, my change didn't make sense.
I've removed the line this._v8CoverageSources!.has(res.url)
so we only rely on shouldInstrument
and added cssTransform.js
to the coveragePathIgnorePatterns
in the other tests. I hope that's ok.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Right, this seems more reasonable to me 👍
"coveragePathIgnorePatterns": [ | ||
"cssTransform\\.js" | ||
] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks breaking for me, because it is only needed with V8 provider. Wouldn’t it be better to keep default behaviour similar between Babel and V8 providers? See alternative proposal in #13974
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm good with your proposal. Thanks!
This pull request has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
Summary
I'm basically continuing the work of: #10657.
If you think it's ok, I'll update the CHANGELOG.md.
Closes #9349
Test plan
I extend v8Coverage.test and compare if the code coverage report goes 100% in each columns as expection.