jestjs / jest

Delightful JavaScript Testing.
https://jestjs.io
MIT License
44.23k stars 6.46k forks source link

No coverage when running in watch mode #7331

Open MurakamiKennzo opened 6 years ago

MurakamiKennzo commented 6 years ago

🐛 Bug Report

when I run jest --watch, I see unknown coverage.

To Reproduce

see Link repo.

Expected behavior

show correct coverage.

Link to repl or repo (highly encouraged)

jest-watch-coverage-bug

Run npx envinfo --preset jest

Paste the results here:

System:
    OS: macOS 10.14
    CPU: x64 Intel(R) Core(TM) m3-6Y30 CPU @ 0.90GHz
  Binaries:
    Node: 9.10.1 - /usr/local/bin/node
    npm: 6.4.1 - /usr/local/bin/npm
  npmPackages:
    jest: ^23.6.0 => 23.6.0 
gabrielbs commented 5 years ago

also happens on ubuntu 18.04

villelahdenvuo commented 5 years ago

Also hitting this issue even though there are changed tests that ran:

 PASS  src/app/product/reducers/product.reducer.spec.ts (6.041s)
 PASS  src/app/shared/services/resolve-store.service.spec.ts (6.706s)

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

Test Suites: 2 passed, 2 total
Tests:       37 passed, 37 total
Snapshots:   0 total
Time:        10.329s
Ran all test suites related to changed files.
  System:
    OS: macOS 10.14.2
    CPU: (4) x64 Intel(R) Core(TM) i5-6360U CPU @ 2.00GHz
  Binaries:
    Node: 11.1.0 - ~/n/bin/node
    Yarn: 1.7.0 - ~/n/bin/yarn
    npm: 6.4.1 - ~/n/bin/npm
  npmPackages:
    jest: ^23.6.0 => 23.6.0
SimenB commented 5 years ago

@MurakamiKennzo what do you expect "correct coverage" to be? All 0? Unless tests actually execute, we have no way of knowing the coverage

villelahdenvuo commented 5 years ago

@SimenB I updated my comment above to be more clear. Tests are ran and coverage works when all tests are ran, but in watch more coverage is not collected even for the files that are affected.

SimenB commented 5 years ago

@villelahdenvuo that's a separate issue from the OP, please include a reproduction (maybe in a new issue)

villelahdenvuo commented 5 years ago

@SimenB How is it different from the OP? According to the example repo included in the OP the issue appears in watch mode after adding a new test. That is my case as well, at first I had no coverage as expected, but then I added a new tests to those two files shown and it still says coverage Unknown.

SimenB commented 5 years ago

Ah, sorry, I missed the step editing the test while watch mode was running.

@stipsan thoughts on how to fix this? You're my goto "coverage in watch mode" guy :D

MurakamiKennzo commented 5 years ago

I agree what @villelahdenvuo said. please follow the step and you will understand what i mean.

stipsan commented 5 years ago

I'll have to look into it more but on top of my head it sounds like the problem is related to the collectCoverageFrom patterns that are added in the runner: https://github.com/facebook/jest/blob/c01b4c75a2f65e9fa122adf69b0ac11875f1fc74/packages/jest-cli/src/runJest.js#L163-L188

So my theory is that it's generating a too exclusive pattern on the first run that is persisted through the second run with the added test.

coxdn commented 5 years ago

I have the same problem. When I delete a folder .git and reinit it (git init), then watch mode displays normally coverage. On repo from topic starter it works too.

Demo

In my case problem manifests on the project a bit larger and wouldn't want to hide this folder every time when I starting npm run test:watch. Maybe there are some workarounds?

GuillaumeAmat commented 5 years ago

Same issue here. When I launch Jest with jest --coverage --watch, without any modified files, the coverage is Unknown% ( 0/0 ).

If I press a, all the tests run, I can see each fail/success state, but the coverage remains Unknown% ( 0/0 ).

If I edit a file, the tests run and again, the coverage is Unknown% ( 0/0 ).

But! If I hit o, the tests run and I see the right coverage! I can then hit a or whatever and all is good :)

kmarple1 commented 5 years ago

I'm getting the same bug, or a variant of it. When I first run npm run test, code coverage for changed files will be correct. However, if I press a or modify additional files, the appropriate tests will be run, but the files won't be added to the coverage report.

miikaah commented 5 years ago

It seems like jest doesn't really respect collectCoverageFrom in watch mode and instead overrides it with files that have changed. If there are no changes, no code coverage is gathered, even if new tests have stepped over new lines. It's a major drag when one has to write tests to a codebase afterwards.

As a workaround I found that you can use forceCoverageMatch to gather coverage even in watch mode.

abierbaum commented 5 years ago

Recently converted to Jest, and this is the only thing missing from my old Karma / jasmine setup. Not having coverage is a pain point for interactive test development. Being able to watch the coverage and gradually increase it through additional tests and IDE extensions that show coverage inline is a huge win if it could work like it does in Karma.

mguida22 commented 5 years ago

It'd be great to have this, is there any update? Is anyone working on a fix?

With a little guidance I'd be happy to contribute to a solution for this.

abierbaum commented 5 years ago

I was able to get everything working fine by simply starting jest with watchAll. Then if I want to see the coverage for a single test I just use 'p' to match the pattern of the file name. Works great. Just confusing to know to use watchAll.

ghost commented 5 years ago

For those who may actually have a different problem:

I fixed mine by simply changing rootDir in package.json to my project directory. It wasn't checking my js files since the default value of rootDir is where jest's config file is (inside test folder in my case).

EmilyRosina commented 5 years ago

Just in case this helps anyone else who does still want to run tests using --watch and compile the code coverage with --coverage...

i.e.

--watch --coverage

I tried moving the unwanted glob file patterns from collectCoverageFrom to coveragePathIgnorePatterns in the jest config file. Needed a bit of tweaking but I can now see coverage without any changes to the npm script :+1:

:warning: collectCoverageFrom uses globs, whereas coveragePathIgnorePatterns uses regex.

before

  collectCoverageFrom: [
    'src/**/*.{js,vue}',
    '!src/main.js',
    '!**/node_modules/**',
    '!src/vendor/**/*'
  ]

after

  collectCoverageFrom: [
    'src/**/*.{js,vue}'
  ],
  coveragePathIgnorePatterns: [
    'src/main.js',
    '/node_modules/',
    'src/vendor/'
  ]

This should probably be in the Jest docs somewhere due to some change that is causing the problem but :woman_shrugging:. I haven't managed to find anything about it, nor a way to only show the coverage for just the 1 suite I am working on/or just files changed. I had also previously tried adding forceCoverageMatch, but this caused all test scripts to collect coverage, which was not desired. Our rootDir was already provided in the config file too, so wasn't that for us either - but thank you for the idea :)


In addition, if this helps anyone on linux: we use Docker - and sometimes it makes root take ownership of the coverage directory and files. So i periodically run

sudo chown -R user:group test/unit/coverage

swap out user and group with your own information.

basickarl commented 5 years ago

Any updates on this?

jlenglain commented 5 years ago

It seems like jest doesn't really respect collectCoverageFrom in watch mode and instead overrides it with files that have changed. If there are no changes, no code coverage is gathered, even if new tests have stepped over new lines. It's a major drag when one has to write tests to a codebase afterwards.

As a workaround I found that you can use forceCoverageMatch to gather coverage even in watch mode.

But this returns coverage for all files for every file change.

jlenglain commented 5 years ago

I was able to get everything working fine by simply starting jest with watchAll. Then if I want to see the coverage for a single test I just use 'p' to match the pattern of the file name. Works great. Just confusing to know to use watchAll.

Can you outline the exact order of the commands you're typing in order to get this to work? I tried your workaround but I get the same result: unknown coverage report.

EmilyRosina commented 5 years ago

I was able to get everything working fine by simply starting jest with watchAll. Then if I want to see the coverage for a single test I just use 'p' to match the pattern of the file name. Works great. Just confusing to know to use watchAll.

yeah.. but i guess that's the limitation with jest, watch and coverage :woman_shrugging: Maybe try changing my command to --watchAll instead as abierbaum suggested and see what happens...

EmilyRosina commented 4 years ago

Seems like it's back to not working for me, unsure if a release broke it or something, no idea :woman_shrugging:.

I can confirm what others say though --watch doesn't work, --watchAll does. It's a pita, but at least it works.

idmick commented 4 years ago

I'm experiencing the same behavior, --watchAll shows coverage, --watch doesn't :(

JimLynchCodes commented 4 years ago

I'm not seeing code coverage calculated correctly at all, regardless of watch mode or not. I have created another issue for this problem here.

ammoradi commented 4 years ago

my problem was the coverage didn't appear after commit test files. in my case, this bug fixed using this command: yarn test --coverage --watchAll

JimLynchCodes commented 4 years ago

My issue has been fixed, and it has to do with the config settings working only in jest.config.js but not under "jest" in package.json. When it works as expected jest it pretty nice! 😄

yomybaby commented 4 years ago

In documentation,

jest --watch #runs jest -o by default
jest --watchAll #runs all tests

jest -o : Run tests related to changed files based on hg/git (uncommitted files)

Abadii commented 4 years ago

I finally got a working configuration.

When the configuration is set in the package.json it won't work. Therefore, I had to create jest.config.js file with the following contents:

module.exports = {
  collectCoverage: true,
  coverageReporters: [
    "html"
  ]
};

And in package.json:

"scripts": {
    "test": "jest --watchAll" // It doesn't work with --watch
}
ps011 commented 4 years ago

Any updates on this ? I am still not getting coverage when combining --collectCoverage and --watch

EmilyRosina commented 4 years ago

@ps011 as mentioned above you need --watchAll not --watch

blopez-dev commented 3 years ago

In order to generate the coverage report, the test script must be: test --watchAll --collect-coverage

hayzey commented 3 years ago

All of these comments saying to use the --watchAll flag are missing the point. The issue is that some of us want to generate coverage without having to run the entire test suite. There are of course issues with this, namely that you wouldn't get an accurate picture of your app's test coverage if you're only generating coverage for changed files.

For example, let's say some files have been changed a few commits ago. You run your unit tests and generate coverage for changed files (i.e, using --watch and not --watchAll). The tests for those files won't be run because they haven't been changed since the last commit. Your coverage report will therefore be wrong.

Perhaps what would be useful is a flag to tell jest to generate coverage for files that have changed since the last time a coverage report was generated. Perhaps in this mode, jest could associate a coverage report with a commit hash. The next time you generate a coverage report, it will do a diff between your current HEAD and that older commit, and rerun tests for any files that have changed since then. If there is no coverage report at all, we run the entire test suite. The flag could be something like:

jest --watch --changedSinceLastCoverageReport

The name could probably be something better but you get the idea. This would fit my use case but I'm not sure about everyone else.

The motivation behind it for me is that some of our bigger test suites can take a long time to run. It's annoying to have to run all of your tests to check the coverage of the files you've been working on.

EmilyRosina commented 3 years ago

I don't prefer having to resort to --watchAll btw :sweat_smile: just so it's not misconstrued :stuck_out_tongue_winking_eye:.

I agree that we should just be able to watch specific file changes only for coverage. Alas, Jest don't allow for this. So please don't assume I've missed the point, I totally get the point - I want it to work that way too!! :pray:

My comments are just to aid those that need coverage and watch to work for them given the current Jest api/options, that's all.

reader00 commented 2 years ago

Previously I also had the problem of coverage not showing. So my folder structure was like this:

D:/some/path/[Submissions]/1/Submission 1

I've done various configurations as suggested above, as well as what I found on Stack Over Flow, but the coverage results are still not showing up.

After a day looking for a way and couldn't find it, I took the initiative to publish the repo to Github, then clone it to D:/, and Voillaaaaa. the coverage result appears.

Then out of curiosity, I cut the clone results to the Submission 1 folder. But the coverage result is gone again.

I did a few experiments, and it turns out that all the code in the [Submissions] folder does not display the coverage result. Then I remember that previously I changed the name of the folder from Submissions to [Submissions], which from that moment the coverage result never shows or is always empty.

After I changed it again to Submissions, everything works.

May this issue occur because of the directory that contains a square bracket([]).

tomavic commented 2 years ago

If it is that simple, by using --watchAll instead of --watch, why is this issue still opened?

ice-blaze commented 2 years ago

@tomavic You don't want to run all the tests every time you execute the tests for the first time. I guess it's fine if your tests suits executes in a few seconds. If it's more than 10 secondes it's start to be annoying.

EmilyRosina commented 2 years ago

@tomavic I personally don't care about coverage for all files when i'm working on just one or a select few. Thus why --watch only generating coverage for specific files you're working on, would be better than --watchAll taking ALL files in your codebase into account.

tomavic commented 2 years ago

@ice-blaze @EmilyRosina

Yes I see. Now I can understand why we should consider --watch over --watchAll

Although, it's weird that it is an opened issue since 2018!!

P.S

What make me came here at first place, I am migrating from Jasmine to Jest, I have 296 test case 😅

I've tried

Jest --coverage --watch

But it didn't generate the coverage.

github-actions[bot] commented 1 year ago

This issue is stale because it has been open for 1 year with no activity. Remove stale label or comment or this will be closed in 30 days.

firebait commented 1 year ago

Don't think this should be closed. The workflow of test coverage with --watchAll is pretty terrible. Is this prioritized?

rafaelrozon commented 1 year ago

Any updates on this? My team recently stopped using --watchAll because it was doing way too much stuff and then we lost the ability to quickly check coverage for changed/watched files. It would be great if coverage worked for both watch flags.

ice-blaze commented 1 year ago

@rafaelrozon As a workaround you can use --watch --test-path-pattern my-current-feature-folder which will run the tests only for a specific scope. It's not ideal because each time you have to specify where you want jest to run but it does the job. No need to wait minutes after each change.

github-actions[bot] commented 1 month ago

This issue is stale because it has been open for 1 year with no activity. Remove stale label or comment or this will be closed in 30 days.

villelahdenvuo commented 1 month ago

Don't think this should be closed. The workflow of test coverage with --watchAll is pretty terrible. Is this prioritized?