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

What does reloadTasks do with regard to __coverage__? #16

Closed
wheresrhys opened this issue Dec 16, 2013 · 7 comments
Closed

What does reloadTasks do with regard to __coverage__? #16

wheresrhys opened this issue Dec 16, 2013 · 7 comments

Comments

@wheresrhys
Copy link

I'm trying to implement an istanbul report on code that's bundled using browserify, using the approach recommended here gotwarlost/istanbul#59 (comment). I've completed every recommended step (I instrument my src, bundle it, then bundle my test files and get them to reference the instrumented src bundle), but using grunt-istanbul ,my reports are always empty.

If I run reloadTasks on my instrumented src files (as you do in your gruntfile) then I do get a report, but it evidently doesn't use my bundled, instrumented src as the results show no code was run even though all the tests run and pass. If I don't run reloadTasks I get Fatal error: No coverage information was collected when running storeCoverage.

All the code is here https://github.com/wheresrhys/on-guard/tree/browserify (note that it's the 'browserify' branch)

@robertgroh
Copy link

Hi whererhys,
unfortunately I have similar problems, but as far as I know reloadTasks tries to find new grunt-tasks in *.js or *.coffeescript files in the specified directory.
Therefore it loads the javascript files (at least from the first directory-layer) from the instrumented folder. These instrumented javascript files set their coverage-object (the coverage.json?) the global variable __coverage__ during loadTasks of grunt.
Therefore the task storeCoverage finds a set global['_coverage__'] variable is found during the task storeCoverage.

taichi (the autor) stated in this #8 (comment), that reloadTasks is used for testing grunt-istanbul itself and no other project need this task.

But I am also unable to get this plugin to work as intended. I don't know at which point the coverage-objects (json files) should be generated, and what is reponsesible to store the coverage-objects to global['_coverage__'] (To be fair: I can't find it also in the istanbul-project -> a certain hint to my minimal unterstanding of node.js).

Currently I help me with a ugly shell task ala istanbul cover --dir build/reports $(readlink -f $(which nodeunit)) -- test.

Any further hint would be gladly appreciated.

@wheresrhys
Copy link
Author

@weemonger You can see at https://github.com/wheresrhys/jigsnreels what I have set up. Not sure how adaptable it'll be to your needs, but take a look anyway

@sblancov
Copy link

sblancov commented Jul 6, 2014

I am trying to use grunt-testem and grunt-istanbul together as you can see bellow, in my Gruntfile.js.
and I get the same error: "Fatal error: No coverage information was collected when running storeCoverage" in storeCoverage task. I have been debugging a little and I have found that "global[options.coverageVar]" is undefined just before https://github.com/taichi/grunt-istanbul/blob/master/tasks/istanbul.js#L45 "options.coverageVar" value is "coverage".
I can not imagine what is coverageVar or what value should be received by "global[options.coverageVar]". Do you figure out how to solve it?

my Gruntfile.js:

module.exports = function(grunt) {

'use strict';

grunt.initConfig({
    clean: ['build/reports/**/*.*'],
    env: {
        coverage: {
            APP_DIR_FOR_CODE_COVERAGE: 'build/instrument/src/'
        }
    },
    storeCoverage: {
        options: {
            dir : 'build/coverage/reports/'
        }
    },
    instrument: {
        files: 'src/**/*.js',
        options: {
            lazy: false,
            basePath: 'build/instrument/'
        }
    },
    makeReport: {
        src: 'build/coverage/reports/**/*.json',
        options: {
            type: ['html', 'lcov'],
            dir: 'build/coverage/reports',
            print: 'detail'
        }
    },
    jshint: {
        options: {
            jshintrc: true,
            reporter: require('jshint-stylish')
        },
        all: ['src/**/*.js', 'test/**/*.js']
    },
    jsdoc : {
        dist : {
            src: ['src/**/*.js'],
            jsdoc: './node_modules/.bin/jsdoc',
            options: {
                destination: 'doc/api',
                configure: './node_modules/grunt-jsdoc/node_modules/jsdoc/conf.json',
                template: './node_modules/grunt-jsdoc/node_modules/ink-docstrap/template'
            }
        }
    },
    testem: {
        env: {
            src: [
                'src/**/*.js',
                'test/**/*.js'
            ],
            report_file: 'build/reports/report.tap',
            options: {
                framework: 'jasmine',
                reporter: 'tap',
                launch_in_dev: [
                    'Chrome'
                ]
            }
        }
    }
});

grunt.loadNpmTasks('grunt-contrib-jshint');
grunt.loadNpmTasks('grunt-contrib-testem');
grunt.loadNpmTasks('grunt-contrib-clean');
grunt.loadNpmTasks('grunt-env');
grunt.loadNpmTasks('grunt-istanbul');
grunt.loadNpmTasks('grunt-jsdoc');

grunt.registerTask('default', ['jsdoc']);
grunt.registerTask('dev', ['testem:run:env']);
grunt.registerTask('build', ['clean', 'jsdoc', 'testem:ci:env']);
grunt.registerTask('coverage', ['clean', 'env:coverage', 'instrument', 'testem:ci:env', 'storeCoverage', 'makeReport']);

};

This is my second day dealing with this full time >.<'

@robertgroh
Copy link

Hi Santiago,

I feel your pain, I took me a while to grok istanbul (and this grunt-plugin).

Regarding your problem, there are two case for this error:

  • your test don't use the instrumented files in build/instrument/src/
  • your tests are run by a other process as the grunt tasks

Istanbul instruments the src files in such a way, that they write the coverage information in a global variable (default: coverage), during their execution.
The value of this global variable can then be write to a .json file by the task storeCoverage.
And with the makeReport task, you generate the coverage report in different formats (lcov, html, cobertura) out of the .json files.

Therefore the test run have to use the instrumented files instead of the normal source files (file path for require() statements - show us your test files). And also the step, when you want to write out the coverage information to .json files, you have to be in the same process as the test run, to access the global variable __coverage__.

I think for your gruntfile, that both cases apply (I don't know testem, so bear with me, if I am wrong).

You let the run against the normal src files:

testem: {
        env: {
            src: [
                'src/**/*.js',

use another grunt task target to specify the instrumented files:

testem: {
        env: { ... },
        coverage: {
            src: [
                'build/instrument/src/**/*.js',
                'test/**/*.js'
             ],
             ...
         }
}

Also it seems to me, that you try to run the tests in a browser (chrome). This will not work with the storeCoverage task. The process in which the task runs (grunt node.js process) is another as the testrun of your (client side?) javascript (chrome process).

So you have to store the coverage information in an other way (cf. gotwarlost/istanbul#16 (comment)).

Some use a afterAll/tearDown method or a separate test case, which will be run at last by their testing framework, to write the content of the global __coverage__ variable to .json files, which can be be used by the makeReport tasks.

I hope this helps.
For further support, you have to tell us more about your project.

@sblancov
Copy link

weemonger, you were right, thank you very much. On the one hand, I had to config the instrumentation as you wrote because was wrong and then, I got it. On the other hand, I have found a faster way to do what I want using grunt-template-jasmine-istanbul. I would like to use testem + istanbul, but it is a little harder so... I give up. Maybe I need to know how nodeJS works.

Anyway, my closest attempt is something like this:
https://gist.github.com/webpro/7644285
I am sure that it could be helpful for any other people.

@reefath
Copy link

reefath commented Jan 25, 2016

Is anyone successful in using this package without 'reloadTasks'? I get the error
Running "storeCoverage" task
Fatal error: No coverage information was collected

I'm trying to get the coverage report for server side ES5 files in a node JS project that uses Grunt for build. Even if I add grunt task for 'reloadTasks' there are lot of errors on the dependencies. Any help is appreciated!

@robertgroh
Copy link

@reefath,
no reloadTasks is need for normal test coverage - it is only used to test grunt-istanbul itself.

As I stated above (quoting myself: #16 (comment)), either:

  • your test don't use the instrumented files during the coverage run, or
  • your tests are run by a other process as the grunt tasks

Istanbul instruments the src files in such a way, that they write the coverage information in a global variable (default: coverage), during their execution.
The value of this global variable can then be write to a .json file by the task storeCoverage.
And with the makeReport task, you generate the coverage report in different formats (lcov, html, cobertura) out of the .json files.

Therefore the test run have to use the instrumented files instead of the normal source files (file path for require() statements - show us your test files). And also the step, when you want to write out the coverage information to .json files, you have to be in the same process as the test run, to access the global variable coverage.

For further help please provide your gruntfile (as a new issue with more details).

@wheresrhys & @taichi: I think this issue can & should be closed.

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

4 participants