-
-
Notifications
You must be signed in to change notification settings - Fork 91
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
Code Coverage reported as 0% after upgrading from 3.0.1 to 4.0.1 #159
Comments
I tried to have a look on what is affecting this, but since it was a major rewrite, I don't think I can pin-down where the problem is without further assistance. |
Just tested it in my project and coverage is also 0% on 4.0.1 gulpfile.js snippet: gulp.task('pre-coverage', function () {
return gulp.src(paths.out + '/src/progress.js')
.pipe(istanbul({includeUntested: true}))
.pipe(istanbul.hookRequire());
});
gulp.task('istanbul', ['pre-coverage'], function () {
return gulp.src(paths.test, {read: false})
.pipe(mocha({reporter: 'spec'}))
.pipe(istanbul.writeReports({
dir: paths.coverage,
reporters: [ 'json' ],
reportOpts: { dir: paths.coverage}
}));
}); |
I think the issue is that gulp-mocha is now acting on files rather than on the stream from the istanbul pipeline. I think this was the tradeoff for making compilers work. :/ You can probably use instanbul to instrument your src into a tmp directory and run the tests against those. |
It always acted on the file paths, not the files object. Nothing has changed in that regard. |
I'm experiencing the same issue after updating |
The problem is that spawning mocha instead use of mocha api. The I think a good solution is make a option that switch between spawn and api. |
Can’t update gulp-mocha to 4.x as long as the issue regarding coverage isn’t fixed: sindresorhus/gulp-mocha#159
Can’t update gulp-mocha to 4.x as long as the issue regarding coverage isn’t fixed: sindresorhus/gulp-mocha#159
Will this ever be solved by a fix in the package?? If not, what are the steps we can take in our own test implementations to work with the new package? |
Any update on this? |
Sounds unlikely. The discussions suggest that there isn't a trivial fix. Consider using |
I would like gulp-mocha to restore compatibility with gulp-istanbul as well. |
Looping in @shellscape , who was the primary author of the v4 updates. @shellscape , do you have any thoughts on how this could be fixed? It seems like v4 swapped one big problem with another big problem. From the changelog:
another option would have been to update the mocha programmatic API so as to avoid the ecosystem issues. If someone wanted to fix this, I'd recommend doing two things:
For now, my plan is to stick to v3 of this lib, but I also have a longer-term goal to switch to Jest. It doesn't seem to make much sense to rely on a patchwork of libs and plugins by many different authors to get basic testing functionality. Jest provides it all out of the box, so the |
pong. I'm not really involved here much anymore, but I'm happy to chime in and then disappear in a puff of smoke... Switching to using the binary was precisely to avoid upstream mocha problems. I can't recall the issue and I haven't the chance to search for the source right now, but the mocha project itself recommended not using the internal API. Unless @sindresorhus has had a change of heart (and I'd doubt it given the number of issues that change resolved) it's unlikely that the module would be reverted to once again use the internal mocha API.
@jmeas I'm not really sure what the purpose of pushing hard for Jest here is - it comes across in poor taste. |
Thanks for the response, @shellscape !
Ah, okay. I didn't know this. My suggestion for how to solve this probably wasn't any good, then.
This a good suggestion. I looked more into that lib, that it's using the "old" programmatic istanbul API. I'm not too sure, but maybe upgrading it to use the new
The purpose was to help other devs get unblocked by this issue. Right now it's not possible to use mocha+istanbul+gulp for coverage without investing a lot of time in the tooling ecosystem, given that many of these libs aren't actively maintained by their creators. I think Jest (or, really, any solution that bundles the integrations for you) is worth consideration for devs running into this specific problem. There are a bunch of other solutions that might make sense for devs, too. You could just use the nyc CLI directly, and skip the gulp ecosystem. Or maybe the Ava/gulp ecosystem works well, too. Or maybe you would choose to invest time to get all of these mocha/coverage/gulp libs working together. I'm not sure – I'm just throwing some options out there for devs who come to this issue. Thanks again, @shellscape ! |
Because we would loose our coverage with gulp-mocha 4.x because of sindresorhus/gulp-mocha#159
Unable to update past 3.0.1 due to change in gulp-mocha operation. see SBoudrias/gulp-istanbul#115 and sindresorhus/gulp-mocha#159.
Hey guys, what is the recommended way of getting code coverage after running |
I am experiencing a weird issue where upgrading
gulp-mocha
from3.0.1
to4.0.1
causes code coverage to no longer work. The tests run as before, but istanbul is no longer able to pick things up and it reports 0% code coverage.This affects this PR https://github.com/ek9/generator-license-cc/pull/25/files
Test coverage before update ( https://travis-ci.org/ek9/generator-license-cc/jobs/195271001 ):
Test coverage after update ( https://travis-ci.org/ek9/generator-license-cc/jobs/205308602 ):
gulpfile.js
For full source you can check the PR or repository ek9/generator-license-cc#25 (comment)
The text was updated successfully, but these errors were encountered: