Coverage 0% - Githubissues

catamphetamine commented 5 years ago

I added nyc before mocha as the documentation suggests and it's giving 0% coverage.

    "test": "mocha --bail --require babel-core/register --require ./test/setup.js \"source/**/*.test.js\" \"test/**/*.test.js\"",
    "test-coverage": "nyc mocha --bail --require babel-core/register --require ./test/setup.js \"source/**/*.test.js\" \"test/**/*.test.js\"",

  141 passing (161ms)

----------|----------|----------|----------|----------|-------------------|
File      |  % Stmts | % Branch |  % Funcs |  % Lines | Uncovered Line #s |
----------|----------|----------|----------|----------|-------------------|
All files |        0 |        0 |        0 |        0 |                   |
----------|----------|----------|----------|----------|-------------------|

3den commented 5 years ago

Im have a similar problem:

ERROR: Coverage for lines (0%) does not meet global threshold (90%)

=============================== Coverage summary ===============================
Statements   : 0% ( 0/2807 )
Branches     : 0% ( 0/1571 )
Functions    : 0% ( 0/1015 )
Lines        : 0% ( 0/2678 )
================================================================================

coreyfarrell commented 5 years ago

We require a link to a demo repository to be able to triage potential bugs.

flintinatux commented 5 years ago

I'm seeing the same thing, but only in TravisCI. And I've got links!

branch: https://github.com/articulate/paperplane/tree/lambda travis results: https://travis-ci.org/articulate/paperplane/jobs/450003744

Would very much appreciate any ideas, because I'm unable to repro locally. It's only in TravisCI.

flintinatux commented 5 years ago

Oh wow. Found the issue. Went back and looked at the Travis runs to see what changed between green and red, and since I was using latest yarn, the version bumped to 1.12.1. When I changed my yarn to a specific version like so:

before_install:
  - npm install -g yarn@1.10.1

That seemed to fix it. Not sure what's up there, but it looks like nyc or one of its deps isn't playing nicely with latest yarn.

klis87 commented 5 years ago

@flintinatux I confirm it, magically nyc stopped working for me locally despite me dependencies were freezed. Then as a last try to solve impossible I tried to use npm not yarn to run coverage command, and suddenly It started working again!

this is my command: "cover": "nyc --reporter=lcov --reporter=text lerna run test:cover" while test:cover in packages is "test:cover": "cross-env BABEL_ENV=coverage mocha -r @babel/register -r chai/register-assert 'src/**/*.spec.js'"

So probably this is yarn bug, but it might have something to do with lerna or nyc too.

onehorsetown commented 5 years ago

Still broken with yarn 1.12.3

jeremad commented 5 years ago

I have the same issue here, it works fine with yarn <= 1.10.1, and it stops working after that. if I use npm or if I run nyc manually everything is fine. So my guess is probably that it is an issue with yarn.

quentinvernot commented 5 years ago

The plot thickens:

"scripts": {
  "test": "mocha something",
  "coverage": "nyc yarn test"
},

Gives no coverage, but it works with nyc npm run test!

jeremad commented 5 years ago

If you want to follow this on yarn side: https://github.com/yarnpkg/yarn/issues/6746

JaKXz commented 5 years ago

Are people still experiencing this issue with the latest yarn?

75lb commented 5 years ago

I'm experiencing the same issue, I don't use yarn. Reproduction case posted here: https://github.com/istanbuljs/nyc/issues/822.

quentinvernot commented 5 years ago

@JaKXz Sadly, it still looks broken:

$ yarn coverage
yarn run v1.13.0
$ nyc --reporter=lcov --reporter=text-summary yarn test
$ mocha "packages/**/src/**/*.spec{,.node}.js" --exit --require ./config/tests/babel.setup.js --require ./config/tests/spec.setup.js --recursive --full-trace --trace-warnings --reporter=spec

...

  111 passing (173ms)

=============================== Coverage summary ===============================
Statements   : Unknown% ( 0/0 )
Branches     : Unknown% ( 0/0 )
Functions    : Unknown% ( 0/0 )
Lines        : Unknown% ( 0/0 )
================================================================================

JaKXz commented 5 years ago

Hmm... Still looks like the signal is not passed on from yarn but I'm not 100% sure... Mind retrying in the yarn issue or making a new one there?

quentinvernot commented 5 years ago

Nevermind, totally works! I had 2 versions of yarn on my system when running this, I used 1.13.0 from the command line, but the other one (in nyc --reporter=lcov --reporter=text-summary yarn test) was still 1.12.3.

Here is what I get when hard-codding the path to yarn:

$ /home/quentin/.npm-packages/bin/yarn coverage
yarn run v1.13.0
$ nyc --reporter=lcov --reporter=text-summary /home/quentin/.npm-packages/bin/yarn test
$ mocha "packages/**/src/**/*.spec{,.node}.js" --exit --require ./config/tests/babel.setup.js --require ./config/tests/spec.setup.js --recursive --full-trace --trace-warnings --reporter=spec

...

  111 passing (303ms)

=============================== Coverage summary ===============================
Statements   : 53.03% ( 184/347 )
Branches     : 64.94% ( 50/77 )
Functions    : 41.84% ( 59/141 )
Lines        : 53.53% ( 167/312 )
================================================================================

morris commented 5 years ago

I'm currently seeing something the other way around: Coverage at 0% when I run "nyc mocha test" but correct coverage when I run the script via npm (npm test where test is "nyc mocha test" in the package.json). nyc @ 13.1.0 in both cases. Interestingly, npm ls -g lists nyc as a dependency of npm?!

Node.js 8.15.0, npm 6.4.1.

Here's my npm ls (in my package) output:

npm ls

and here's npm ls -g:

JaKXz commented 5 years ago

@morris your issue sounds like it's different from the original... would you mind trying to reproduce it in a minimal example repo and opening a new issue when you do? Also, nyc is a dependency of npm since I'm pretty npm uses nyc for coverage :)

One minor thing, I hope you don't mind, I edited your comment for thread readability.

@quentinvernot thank you for sharing! Are we satisfied to close this issue?

quentinvernot commented 5 years ago

Looks good to me, keep in mind that yarn's 1.13.0 is a pre-release, so it's not really fixed yet, but it was never nyc's fault in the first place. Up to you.

JaKXz commented 5 years ago

Great, thanks!

onehorsetown commented 5 years ago

Just tried yarn 1.13.0 via brew and the problem still persists.

quentinvernot commented 5 years ago

@onehorsetown Okay, just upgraded my real yarn to 1.13.0 and removed my little hack with the hardcoded path, and... it doesn't work. If I keep the hardcoded path (with /usr/bin/yarn this time) it works though.

It gets weirder, I made nyc run which yarn just in case:

{
  "scripts": {
    "coverage": "nyc --reporter=lcov --reporter=text-summary which yarn"
  }
}

And got this:

$ yarn coverage
yarn run v1.13.0
$ nyc --reporter=lcov --reporter=text-summary which yarn
/tmp/yarn--1547824229222-0.5258100608719858/yarn

Here is the content of this /tmp/yarn--1547824229222-0.5258100608719858/yarn:

#!/bin/sh

exec "/usr/bin/node" "/usr/bin/yarn" "$@"

It's a new tmp file every time btw. It looks like yarn is doing this, no idea why so far... Probably don't reopen this issue, doesn't look like it's nyc's fault.

jdoubleu commented 5 years ago

symptoms

I had the exact same problems:

Running coverage locally worked
Running coverage in CI didn't

setup

I am using nyc with mocha to test native NodeJS code without any transpiler.

npm

I am using npm so this yarn issue didn't apply. I even updated npm locally (to 6.7.0) to check whether it would be broken like in the yarn case. But it worked fine.

node

Another difference between the CI environment and my local one was the NodeJS version.

Locally I was using v11.6,
In CI the version was v11.7, since I was using the latest node version

Then I tested coverage with both versions and it seems like v11.6 is working but v11.7 isn't. There are no errors displayed, whatsoever.

conclusion

I don't know if the yarn bug from above is just another issue or it has something todo with node.

If someone can confirm this issue with node v11.7 it might be a new issue.

IvanGoncharov commented 5 years ago

@jdoubleu It's a new issue that triggered by node 11.7, more details here: https://github.com/nodejs/node/issues/25650

sjl2 commented 5 years ago

Can confirm that the same behavior occurs on Node 8.10.0 as discussed here: https://github.com/yarnpkg/yarn/issues/6746.

AnanyaJha commented 5 years ago

I'm having the same issue with Node 8.9.4 using npm nyc & mocha, more details here: https://github.com/istanbuljs/nyc/issues/822#issuecomment-460467601

In reimplementing the 'testrunner' file that comes with codecov, we have the following methods that interact with mocha

      mocha
        .run((failures: any) => {
          process.on('exit', () => {
            console.log(
              `Existing test process, code should be ${failureCount}`
            );
            process.exit(failures); // exit with non-zero status if there were failures
          });
        })
        .on('fail', (test: any, err: any): void => {
          console.log(`Failure in test '${test}': ${err}`);
          failureCount++;
        })
        .on('end', (): void => {
          console.log(`Tests ended with ${failureCount} failure(s)`);
          clb(undefined, failureCount);
        });
    } catch (error) {
      console.error('An error occured: ' + error);
      return clb(error);
    }

which use the functionality that was referenced here (https://github.com/nodejs/node/issues/25650) with the process.exit() and process.on(exit) no longer working together, but we are still in Node 8.9.4

worc commented 5 years ago

also broken on yarn 1.13.0 and node 10.15.1

danielsss commented 5 years ago

also broken on lerna

wmenegali commented 5 years ago

For me, it works on node v10.15 using NPM but not with yarn (v1.13.0).

jcolemorrison commented 5 years ago

Same for me @wmenegali . Looks to be a yarn issue.

worc commented 5 years ago

still broken on yarn 1.15.2 and node 10.15.3, but i did find a workaround. you can still use yarn to call into the coverage script, but you have to run your tests with npm in order for nyc to actually pick up on the metrics coming out of the tests.

hkmarques commented 5 years ago

Still facing the issue with yarn v1.16.0, using npm to run the tests like @worc suggested does the trick.

troskoff commented 4 years ago

yarn 1.17.3, nyc 14.1.1 - still the same problem

narwajea commented 4 years ago

Same here: https://github.com/yarnpkg/yarn/issues/6746#issuecomment-555515820

vineeshtp commented 4 years ago

This solved my issue. https://stackoverflow.com/questions/61220138/mocha-chai-coverage-unknown

aubreyyan commented 4 years ago

not for me

monsam commented 4 years ago

same issue, why the hell the ticket is closed?

monsam commented 4 years ago

even worse when I hardcode the yarn path I get FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory

eechava6 commented 3 years ago

Same issue here

idanElitzur commented 1 year ago

Are there any news regarding this issue? I'm facing with the same issue with cy v11.1

getting the error below: Cannot find coverage file /Users/myuser/repos/myrepo/.nyc_output/out.json Skipping coverage report

=============================== Coverage summary ===============================
Statements   : Unknown% ( 0/0 )
Branches     : Unknown% ( 0/0 )
Functions    : Unknown% ( 0/0 )
Lines        : Unknown% ( 0/0 )
================================================================================

@catamphetamine @3den

ghsouza89 commented 1 year ago

is this closed for which reason? is the fix in another ticket?

JudithVanDongen-Kramp commented 1 month ago

I had this error when I converted to ES6 modules. Reverting to CommonJS fixed the issue for me.

istanbuljs / nyc

Coverage 0% #921

symptoms

setup

npm

node

conclusion