-
Notifications
You must be signed in to change notification settings - Fork 247
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
Browserify + coverage doesn't work #16
Comments
👍 this |
FWIW, I've recently migrated over to using the karma-commonjs lib @vojtajina has been working on. Still running into a dead-end in getting it to work with karma-coverage. trying to find a hack to get it to work. |
GOT IT WORKING. I'm using grunt-karma. Pointed my dependency to the https://github.com/karma-runner/grunt-karma#master branch (using karma 0.11), karma-commonjs and karma-coverage. PLEASE NOTE: you're going to run into dependency mismatch issues unless your versions of both karma-commonjs and karma-coverage have a dependency on karma 0.11. My karma.conf.js file looks like this:
|
Does the path
|
@morganrallen no. I just checked my config again and that had changed. preprocessor should be:
sorry for the mixup |
+1 |
I have a workaround for this (which isn't pretty, but it works like a charm):
|
@quarterto I've been attempting the exact same solution you described, but the The key part of my Karma config looks like this: preprocessors: {
'test/spec/*Spec.js': 'browserify'
},
reporters: ['progress', 'coverage'],
coverageReporter: {
type : 'lcov',
dir : 'test/coverage'
}, The specs require the instrumented code from |
Hmm, not sure what's going on there. I don't have a config I can share (it's a proprietary app) but there's nothing in yours that looks like it won't work. Do note that I'm using karma-browserifast instead of karma-browserify, but I'm not sure that would make the difference. How are you instrumenting your code? |
Hi, I'm using karma-bro + browserify + angular. |
i’m manually instrumenting the code and requiring it, per what is discussed here: karma-runner/karma-coverage#16
+1 |
@quarterto I sorta got it working with your method when trying it with one directive's test. It generated the 'Loaded directive multiple times' error, but still gave me a possible correct coverage value. Did you get this? |
@Nathan219 I'm not using Angular so I can't really help with that. |
@thaiat Any progress? What you're describing is exactly what I'm seeing, too. The tests work just fine, but trying to get the coverage to function properly is not working. We see 100% code coverage on files where there are no tests written. |
As a work-around, I'm using:
Dependencies include: Issues:
|
Hey guys, Cheers! |
@eib You are amazing. That totally did the trick! 👍 |
hey everyone, i have developed a yeoman generator where you can see how i get everything working together with minimum config. Let me know what you think |
Thanks @uxtx your solution worked perfectly for me. |
Glad it worked! |
Notes: - browserify-istanbul is used instead of a karma-coverage preprocessor because of this bug: karma-runner/karma-coverage#16 (comment) - karma-coverage version pinned to 0.2.6 to workaround this bug: karma-runner/karma-coverage#123 (comment)
Notes: - browserify-istanbul is used instead of a karma-coverage preprocessor because of this bug: karma-runner/karma-coverage#16 (comment) - karma-coverage version pinned to 0.2.6 to workaround this bug: karma-runner/karma-coverage#123 (comment)
Hi, I found that using @eib's strategy works for generating code coverage reports, but it won't actually write the ERROR [coverage]: [TypeError: Cannot read property 'split' of undefined]
TypeError: Cannot read property 'split' of undefined
at HtmlReport.Report.mix.writeDetailPage (D:\Documents and Settings\My Documents\Projects\Avalon-Core\Repository\node_modules\istanbul\lib\report\html.js:396:30)
at D:\Documents and Settings\My Documents\Projects\Avalon-Core\Repository\node_modules\istanbul\lib\report\html.js:473:26
at SyncFileWriter.extend.writeFile (D:\Documents and Settings\My Documents\Projects\Avalon-Core\Repository\node_modules\istanbul\lib\util\file-writer.js:57:9)
at FileWriter.extend.writeFile (D:\Documents and Settings\My Documents\Projects\Avalon-Core\Repository\node_modules\istanbul\lib\util\file-writer.js:147:23)
at D:\Documents and Settings\My Documents\Projects\Avalon-Core\Repository\node_modules\istanbul\lib\report\html.js:472:24
at Array.forEach (native)
at HtmlReport.Report.mix.writeFiles (D:\Documents and Settings\My Documents\Projects\Avalon-Core\Repository\node_modules\istanbul\lib\report\html.js:466:23)
at D:\Documents and Settings\My Documents\Projects\Avalon-Core\Repository\node_modules\istanbul\lib\report\html.js:468:22
at Array.forEach (native)
at HtmlReport.Report.mix.writeFiles (D:\Documents and Settings\My Documents\Projects\Avalon-Core\Repository\node_modules\istanbul\lib\report\html.js:466:23)
at HtmlReport.Report.mix.writeReport (D:\Documents and Settings\My Documents\Projects\Avalon-Core\Repository\node_modules\istanbul\lib\report\html.js:550:14)
at D:\Documents and Settings\My Documents\Projects\Avalon-Core\Repository\node_modules\karma-coverage\lib\reporter.js:138:24
at D:\Documents and Settings\My Documents\Projects\Avalon-Core\Repository\node_modules\karma\lib\helper.js:87:7
at FSReqWrap.oncomplete (fs.js:77:15) However if I allow istanbul's reporter to use the standard fslookup store, everything works fine and I'm able to get properly highlighted reports. |
I'm getting the exact same error as above. @weikinhuang how do you allow istanbul's reporter to use the standard fslookup store? |
@alexbardas per issue #123 downgrading to v0.2.6 solves it for now, until #124 is merged. |
Thanks very much @weikinhuang , I confirm that it works. I hope your pull request will get accepted soon. |
@eib Sorry if I'm misunderstanding but I don't understand how the HTML coverage report can work. Istambul is running on the transpiled ES5 code, so coverage numbers are based on that, not the original ES6 files. That's what I'm seeing, am I missing something? |
Should be fixed in master, in the new release that's going out later today |
Why is this closed as none of the solutions appear to be working. browserify-istanbul still does not ignore dependencies. I guess this is more istanbul's problem? |
Coverage did not show correct results, after doing some research I could make it work. This is solved by using browserify-istanbul as commented here: karma-runner/karma-coverage#16
@eib well, about a year later, your answer still solved my issue. Thanks! |
This is still a problem. |
- proper Browserify support: karma-runner/karma-coverage#16 (comment) Closes #21.
Well is there some straight forward way karma-browserify and karma-coverage to work together since its 2016 now :) ? |
Better to use tools such as Mocha, Istanbul, Isparta etc as I'm doing right now. It's way easier to configure, manage and faster as compared to use them behind a curtain "recommended" solution: Karma. |
Isparta is pretty outdated and does not work correctly with ES6 - coverage seems to be out of sync with transmuted source. I have already pointed out a recipe here that works well with Karma, browserify and ES6, so here it is again - https://github.com/istanbuljs/babel-plugin-istanbul |
@stsvilik The point is not Isparta. Point is: "Using tools directly". Thx anyway. |
@DeeperX What I've sent can be used w/o Karma (and probably works better too). My point though is if you're recommending tools, please make sure those tools are up to the task otherwise it'll waste valuable time for users (speaking from experience). |
@stsvilik Thanks for the clarification. But I was not recommending any tool. I've clearly described my point on my previous post already. |
If you use the karma-browserify plugin together with this plugin, it doesn't work. As far as I can tell, both preprocessors take the same files and then do their magic. What would actually be needed, is that the output of the first preprocessor is the input for the second one. Is there a solution to this?
The text was updated successfully, but these errors were encountered: