Skip to content
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

Closed
ghost opened this issue Sep 12, 2013 · 35 comments
Closed

Browserify + coverage doesn't work #16

ghost opened this issue Sep 12, 2013 · 35 comments

Comments

@ghost
Copy link

ghost commented Sep 12, 2013

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?

@uxtx
Copy link

uxtx commented Nov 1, 2013

👍 this

@uxtx
Copy link

uxtx commented Nov 2, 2013

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.

@uxtx
Copy link

uxtx commented Nov 4, 2013

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:

module.exports = function(config) {
    config.set({

        'basePath': '../..',

        'frameworks': ['jasmine', 'commonjs'],

        'files': [
            'node_modules/lodash/lodash.js',
            'build/scripts/angular.min.js',
            'assets/vendor/angular-mocks/angular-mocks.js',
            'client/**/*',
            'tests/webclient/unit/**/*'
        ],

        // possible values: 'dots', 'progress', 'junit', 'growl', 'coverage'

        'preprocessors': {
           '**/client/**/*': ['commonjs', 'coverage']
        },

        'reporters': ['coverage','progress'],

        'coverageReporter': {
          'type' : 'html',
          'dir' : 'coverage/'
        },

        // web server port
        'port': 9876,

        // enable / disable colors in the output (reporters and logs)
        'colors': true,

        // level of logging
        // possible values: config.LOG_DISABLE || config.LOG_ERROR || config.LOG_WARN || config.LOG_INFO || config.LOG_DEBUG
        'logLevel': config.LOG_INFO,

        // enable / disable watching file and executing tests whenever any file changes
        'autoWatch': false,

        // Start these browsers, currently available:
        // - Chrome
        // - ChromeCanary
        // - Firefox
        // - Opera
        // - Safari (only Mac)
        // - PhantomJS
        // - IE (only Windows)
        'browsers': ['Chrome', 'PhantomJS'],

        // If browser does not capture in given timeout [ms], kill it
        'captureTimeout': 60000,

        // Continuous Integration mode
        // if true, it capture browsers, run tests and exit
        'singleRun': true,

    })
}

@morganrallen
Copy link

Does the path **/client/**/.js have some significance or is it specific to your project? I've duplicated your config and made a fake project but get

PhantomJS 1.9.2 (Linux) ERROR
    ReferenceError: Can't find variable: require
    at /tmp/test-test/src/main.js:1

@uxtx
Copy link

uxtx commented Nov 19, 2013

@morganrallen no. I just checked my config again and that had changed. preprocessor should be:

        'preprocessors': {
           'client/**/*': ['commonjs', 'coverage']
        },

sorry for the mixup

@wheresrhys
Copy link

+1

@apaleslimghost
Copy link

I have a workaround for this (which isn't pretty, but it works like a charm):

  • Copy your scripts to another folder (where your tests can still require them)
  • Instrument your copied scripts manually (I use grunt-istanbul)
  • Have your test files require the instrumented files
  • Use the browserify preprocessor on your test files

@markdalgleish
Copy link

@quarterto I've been attempting the exact same solution you described, but the coverage reporter doesn't seem to recognise my manually-instrumented code.

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 lib-instrumented and it's passing all the tests but, digging into the reporter code, the result object doesn't have a coverage property. Do you have an example somewhere online I can look at?

@apaleslimghost
Copy link

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?

@thaiat
Copy link

thaiat commented Jun 9, 2014

Hi,

I'm using karma-bro + browserify + angular.
The result i get from coverage is that 100% of the files under test are covered which is not true.
Any idea how to make this work?

robertjd pushed a commit to stormpath/stormpath.js that referenced this issue Jul 8, 2014
i’m manually instrumenting the code and requiring it, per what is
discussed here:

karma-runner/karma-coverage#16
@BlueHotDog
Copy link

+1

@Nathan219
Copy link

@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?

@apaleslimghost
Copy link

@Nathan219 I'm not using Angular so I can't really help with that.

@guahanweb
Copy link

@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.

@eib
Copy link

eib commented Nov 7, 2014

As a work-around, I'm using:

  • karma-bro, because karma-browserify had issues
  • browserify-istanbul browserify transform to instrument the files, because it plays nicely with other browserify transforms -- whereas karma-commonjs doesn't (e.g. browserify-shim and brfs)
  • karma-coverage to generate the coverage reports
var es6ify = require('es6ify'),
  brfs = require('brfs'),
  istanbul = require('browserify-istanbul');

es6ify.traceurOverrides = { sourceMaps: true };

module.exports = function(config) {
  config.set({
    ...
    frameworks: ['jasmine', 'browserify'],
    files: [
      { pattern: 'www/js/vendor.js', included: true, watched: false }, /* A concatenation of Bower deps */
      { pattern: 'test/runner/specHelper.js', included: true, watched: true }, /* jasmine helpers, etc */
      { pattern: 'test/**/*Test.js', included: true, watched: true },
    ],
    preprocessors: {
      'test/**/*Test.js': ['browserify'],
    },
    reporters: ['coverage', /*and others*/],

    browserify: {
      debug: true,
      transform: [es6ify, brfs, 'browserify-shim', istanbul({
        ignore: ['**/node_modules/**', '**/test/**'],
      })],
    },
    coverageReporter: {
      reporters: [
        { type: 'html', /*other options*/ },
        { type: 'cobertura', /*other options*/ },
      ],
    },
    ....
  });
};

Dependencies include:
"brfs": "^1.2.0",
"browserify": "^6.2.0",
"browserify-istanbul": "^0.1.2",
"karma": "^0.12.24",
"karma-bro": "^0.8.0",
"karma-coverage": "^0.2.6",

Issues:

  • I'm still getting sourceMap-related errors
  • Test file coverage is kind of meaningless: if it's been bundled, then it's obviously been covered at least once
  • My ./test/**/* files are showing up in my cobertura reports -- but only on my CI server

@ashishpundalik
Copy link

Hey guys,
I just wanted to know if there are any updates on resolving this issue.
Please let me know.

Cheers!

@Nathan219
Copy link

@eib You are amazing. That totally did the trick! 👍

@thaiat
Copy link

thaiat commented Nov 8, 2014

hey everyone, i have developed a yeoman generator where you can see how i get everything working together with minimum config.
the repo is here: https://github.com/thaiat/generator-angular-famous-ionic

Let me know what you think

@jednano
Copy link

jednano commented Dec 5, 2014

Thanks @uxtx your solution worked perfectly for me.

@uxtx
Copy link

uxtx commented Dec 5, 2014

Glad it worked!

treyhunner added a commit to startersacademy/fullstack-project-01 that referenced this issue Feb 17, 2015
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)
treyhunner added a commit to startersacademy/fullstack-project-01 that referenced this issue Feb 18, 2015
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)
@weikinhuang
Copy link
Contributor

Hi, I found that using @eib's strategy works for generating code coverage reports, but it won't actually write the html reports with the following error:

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.

@alexbardas
Copy link

I'm getting the exact same error as above.

@weikinhuang how do you allow istanbul's reporter to use the standard fslookup store?

@weikinhuang
Copy link
Contributor

@alexbardas per issue #123 downgrading to v0.2.6 solves it for now, until #124 is merged.

@alexbardas
Copy link

Thanks very much @weikinhuang , I confirm that it works. I hope your pull request will get accepted soon.

@rysilva
Copy link

rysilva commented Apr 30, 2015

@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?

@dignifiedquire
Copy link
Member

Should be fixed in master, in the new release that's going out later today

@nmccready
Copy link

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?

jotaoncode added a commit to jotaoncode/web-istanbul-browserify that referenced this issue Nov 1, 2015
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
@roboshoes
Copy link

@eib well, about a year later, your answer still solved my issue. Thanks!

@inancgumus
Copy link

This is still a problem.

niksy added a commit to niksy/generator-paleta that referenced this issue Jun 24, 2016
@gauravsoni1
Copy link

Well is there some straight forward way karma-browserify and karma-coverage to work together since its 2016 now :) ?

@inancgumus
Copy link

inancgumus commented Oct 31, 2016

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.

@stsvilik
Copy link

stsvilik commented Nov 3, 2016

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

@inancgumus
Copy link

@stsvilik The point is not Isparta. Point is: "Using tools directly". Thx anyway.

@stsvilik
Copy link

stsvilik commented Nov 5, 2016

@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).

@inancgumus
Copy link

@stsvilik Thanks for the clarification. But I was not recommending any tool. I've clearly described my point on my previous post already.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests