Jest: Is there a way to have code coverage in the Javascript Jest testing framework?

[puliaiev]

[simenbrekken]

Jest will collect coverage information with --coverage but there's a TODO in defaultTestResultHandler.js where the output implemtation should be.

I've hacked together a very crude output implementation that just prints all uncovered spans:

if (config.collectCoverage) {
  Object.keys(testResult.coverage).forEach(function(filename) {
    var coverageData = testResult.coverage[filename];
    var lines = coverageData.sourceText.split('\n');

    coverageData.uncoveredSpans.forEach(function(span, index) {
      console.log('Span #' + index);
      var start = span.start.line;
      var end = Math.max(span.end.line, span.start.line + 1);
      var segment = lines.slice(start, end);

      var block = segment.map(function(line, index) {
        return (span.start.line + index) + ': ' + line;
      }).join('\n');

      console.log(block + '\n');
    });
  });
}

[simenbrekken]

Coverage information seems to be incorrect for asynchronous tests however, in the following test the asyncPromiseFunction is reported as uncovered.

var asyncPromiseFunction = function() {
  return Promise.resolve('foo')
}

pit('should cover something async', function() {
  return asyncPromiseFunction()
})

[puliaiev]

I've tried to use istanbul:

istanbul cover node_modules/jest-cli/bin/jest.js

But got error:

No coverage information was collected, exit without writing coverage information

[puliaiev]

@sbrekken thank you for your answer, but it does not help me.

[jeffmo]

@SevaUA: What happens if you run istanbul with single-process jest? (i.e. with the --runInBand command line option)

I'm not completely sure how istanbul gathers coverage, but jest boots several processes by default and runs tests in a worker pool, so those child processes may be getting past it?

[jeffmo]

@sbrekken: Good to know, WRT async tests -- we should look into that. I've been pretty pre-occupied with vacation/travel the last month or so...but I'm ramping back up now so hopefully I can devote some more time to this stuff again in the next couple of weeks.

[ScottMaclure]

They really should get coverage up and running, else I fail to see the point of using Jest for TDD.

Note that you cannot use Istanbul with Jest for coverage:

https://github.com/gotwarlost/istanbul/issues/220#issuecomment-49512538

[ezequiel]

@jeffmo Is this something that's currently being worked on?

[jeffmo]

@ezequiel : I don't know of anyone working on this at the moment and unfortunately I'm spread pretty thin on my team these days :/ That said, I'd be happy to try to find some time to look at pull requests if you want to take a crack at this?

[rtorr]

I don't like :+1:ing an issue, but I really want to show interest here.

[carystanley]

:+1: I think Jest is awesome and I really want to use it on my latest project, but without code coverage we will have to use something else :weary:

[yamalight]

Any updates here?
It seems that it's not just output - tried running coverage for my current project with one React component with basic output code from @sb given before, but it returns some very strange results and nothing about the actual project code.

[ronjouch]

@jeffmo @simenbrekken do you feel that @simenbrekken 's approach in https://github.com/facebook/jest/issues/101#issuecomment-50983550 is a reasonable starting point for a more complete implementation, or would deeper work (in jest? istanbul?) be needed to properly support coverage?

[jeffmo]

@ronjouch : I think so, yes. I'd be happy to take a pull request that includes some kind of printed coverage info in the CLI output if --collectCoverage is specified!

[hankhsiao]

https://github.com/facebook/jest/pull/178
This is a way to hook to Istanbul.

[hankhsiao]

@SevaUA @ronjouch, I just integrated Istanbul into Jest, maybe you guys can try and give me some feedback. I checked CoverageCollector Facebook used is cover (https://github.com/itay/node-cover), and it is a little bit buggy, although they use the same parser Esprima. For example, break; statement won't be covered in switch.

[securingsincity]

@hankhsiao this looks awesome! i gave it a try locally and was able to _finally_ get coverage for my react components. One thing i noticed right away is the onlyCollectFrom functionality is rough. this is probably a separate issue but it would be much better to have ignore paths for collection rather than what it has now where it tries to build its own onlyCollectFrom if one isn't set. Having to explicitly set each file that you are covering's path is a pain especially when you have a larger project.

[hankhsiao]

@securingsincity I agree. Right now I don't hear any feedback from Facebook, so I don't want to go further util they merge some PRs or discuss with me. But I will still work on it.

[securingsincity]

Yeah love it! its a game changer for me and something Jest desperately needed. Hopefully they merge soon.

[mattnorris]

First of all, thank you, @hankhsiao and @jeffmo, for such a great enhancement. It is making a world of difference for my team and me.

I noticed that with your branch, @hankhsiao, before it was merged, I could see coverage for stores as well as components. With Jest 0.3.0, it seems that this is gone. Is this true or is there a nuance I'm not aware of?

[hankhsiao]

I am working fine with Jest 0.3.0. All code between my branch and Jest 0.3.0 should be the same. Could you confirm again that if you switch to my branch and it works?

[mattnorris]

This was with Jest 0.2.1 or 0.2.2. I had your branch awhile ago. (I just confirmed your latest branch is consistent with Jest's main branch.) It's strange because I see that the Jest tests are run on the stores, but coverage only includes the components.

[mattnorris]

@hankhsiao Here is the code in question: https://gist.github.com/mattnorris/6e91d27972bc6f37321c. I would expect the store test to cover the store since it calls its getter and setter methods.

[hankhsiao]

OK, the problem is the path variable require(CONSTANTS_PATH);. Jest is kind of a file parser which will parse all of your test files and find out the pattern require() and extract the file name. In your case, it extracted 'CONSTANTS_PATH' which is not a valid path, and be ignored. Try to write require('../constants/Constants') and it will work.

[akshayp]

@mattnorris It seems like the module loader is unable to find all the files being required if they're not explicitly in a require('some string'). I have a test where the required module is being done in a util and jest completely ignores that the file is being covered

[mattnorris]

Wow! You guys are amazing. That was _killing_ me. Thank you so much!
:100:

[akshayp]

@mattnorris Issue filed here https://github.com/facebook/jest/issues/268

[hankhsiao]

@SevaUA, this is not an issue anymore, and can be closed.

[ghost]

Thank you for reporting this issue and appreciate your patience. We've notified the core team for an update on this issue. We're looking for a response within the next 30 days or the issue may be closed.

[migueldelmazo]

hi, in my company we have found a solution for getting code coverage: http://blog.redradix.com/get-coverage-reports-with-jest-js-react/

[PainKKKiller]

@migueldelmazo link is broken