jest: Wrong coverage when using arrow function with return

Repository: https://github.com/nelsyeung/eslatest-lib-template/tree/43893c5c4a65131a82fad6392eb0e6fab23ad91b

git clone https://github.com/nelsyeung/eslatest-lib-template.git
cd eslatest-lib-template
npm i
npm test

The repository at its current state produces 100% functions coverage, which is correct. However, when I switch to arrow function with direct return, i.e., change the src/library.js code to:

import { find } from 'core-js/es6/array';

export default class {
  constructor() {
    this.helloWorld = [{ text: 'hello' }, { text: 'world' }, { text: '!' }];
  }

  world() {
    return find(this.helloWorld, t => t.text === 'world');
  }
}

the coverage report will now show only 66% coverage for functions:

 PASS  src/library.test.js
  ✓ Library ES6 code runs perfectly (4ms)

Test Suites: 1 passed, 1 total
Tests:       1 passed, 1 total
Snapshots:   0 total
Time:        0.713s, estimated 1s
Ran all test suites.
------------|----------|----------|----------|----------|----------------|
File        |  % Stmts | % Branch |  % Funcs |  % Lines |Uncovered Lines |
------------|----------|----------|----------|----------|----------------|
All files   |      100 |      100 |    66.67 |      100 |                |
 library.js |      100 |      100 |    66.67 |      100 |                |
------------|----------|----------|----------|----------|----------------|

Versions: OS: macOS High Sierra Node: 8.9.1 npm: 5.5.1

About this issue

  • Original URL
  • State: closed
  • Created 7 years ago
  • Reactions: 1
  • Comments: 17 (4 by maintainers)

Commits related to this issue

Most upvoted comments

@SimenB I am still experiencing this with jest@24.8.0, when I run coverage, I can see coverage is skipped for any and all arrow functions completely. Any suggestions to fix?

This should be fixed now as the babel 7 compatibility PRs were just merged and released. See istanbul-lib-instrument@1.9.2

Definitely caused by a major change in babylon (no longer including expression flag on ArrowFunctionExpression). I’ve got a PR open to fix this in istanbul – while not ideal, in the meantime you can get the proper values by hotfixing ./node_modules/istanbul-lib-instrument/dist/visitor.js:

diff --git a/node_modules/istanbul-lib-instrument/dist/visitor.js b/node_modules/istanbul-lib-instrument/dist/visitor.js
index 79744ab..b56a272 100644
--- a/node_modules/istanbul-lib-instrument/dist/visitor.js
+++ b/node_modules/istanbul-lib-instrument/dist/visitor.js
@@ -394,7 +394,7 @@ function parenthesizedExpressionProp(prop) {
 function convertArrowExpression(path) {
     var n = path.node;
     var T = this.types;
-    if (n.expression) {
+    if (n.expression || n.body.type !== 'BlockStatement') {
         var bloc = n.body.loc;
         n.expression = false;
         n.body = T.blockStatement([T.returnStatement(n.body)]);

I have the same problem. And what I found out. Let’s try a simple example with a wrong coverage.

export const isString = string =>
  typeof string === 'string'

export const isArrayOfString = array =>
  Array.isArray(array) && array.every(isString)

If I don’t want to wait for some patches I add ignore comments. But it’s still wrong. It doesn’t matter whether an one line or a multiline code.

// istanbul ignore next
export const isString = string =>
  typeof string === 'string'

// istanbul ignore next
export const isArrayOfString = array =>
  Array.isArray(array) && array.every(isString)

So if I separate constant declarations & export then it works!

// istanbul ignore next
const isString = string =>
  typeof string === 'string'

// istanbul ignore next
const isArrayOfString = array =>
  Array.isArray(array) && array.every(isString)

export {
	isString,
	isArrayOfString,
}

Which exact package shall I log this issue to though?

Still, adding a big warning in the docs would avoid this kind of surprise, don’t you think @cpojer ?

@WaldoJeffers can confirm I see the same thing. Not sure why.

I can confirm this, using Jest v21.2.1 and Babel 7. Using arrow functions will lower your % Funcs. This is really frustrating. I think this is caused by Babel 7. I used Babel 6, and my % Funcs was 100%, then upgraded to Babel 7 and it went down to 0%. I followed every instruction regarding the use of Babel 7, but there’s clearly something wrong with that. I suggest adding a serious warning or enforcing Babel 6.x. @nelsyeung what Babel version were you using?