Jest: Coverage is not generated inside a Vagrant virtual machine

[StephanBijzitter]

Our setup works on any local machine, OS X or Windows, without any issues.
However, we always prefer to use our virtual machine to develop on, as it's configured just like our live servers. Sadly, coverage is not generated (and it appears that tests are not even executed) when running on Vagrant. All other Jest functions (or at least the ones we make use of) do work as expected.

When running on Vagrant (Ubuntu 14.04):

vagrant@vagrant-ubuntu-trusty-64:/vagrant$ npm run unit

> <redacted>[email protected] unit /vagrant
> mkdir -p coverage && jest --coverage --verbose

Using Jest CLI v12.0.2, jasmine2
vagrant@vagrant-ubuntu-trusty-64:/vagrant$ 

When running on OS X (El Capitan):

Stephans-MacBook-Pro:<redacted>-Node stephanbijzitter$ npm run unit

> <redacted>[email protected] unit /Users/stephanbijzitter/<redacted>-Node
> mkdir -p coverage && jest --coverage --verbose

Using Jest CLI v12.0.2, jasmine2
 PASS  modules/module-b/spec/ModuleB.spec.js (0.043s)
ModuleB
  #constructor
    ✓ it should export a class by default
  #foo
    ✓ it should be a static function

 PASS  modules/module-a/spec/util/SomeClass.spec.js (0.036s)
SomeClass
  #constructor
    ✓ it should export a class by default
  #bar
    ✓ it should return "foobar"

 PASS  modules/module-b/spec/util/SomeOtherClass.spec.js (0.036s)
SomeOtherClass
  #constructor
    ✓ it should export a class by default
  #bar
    ✓ it should return "foobar"

 PASS  modules/module-a/spec/ModuleA.spec.js (0.04s)
ModuleA
  #constructor
    ✓ it should export a class by default
  #foo
    ✓ it should be a static function

8 tests passed (8 total in 4 test suites, run time 1.027s)
--------------------|----------|----------|----------|----------|----------------|
File                |  % Stmts | % Branch |  % Funcs |  % Lines |Uncovered Lines |
--------------------|----------|----------|----------|----------|----------------|
 module-a/src/      |       75 |      100 |        0 |       75 |                |
  ModuleA.js        |       75 |      100 |        0 |       75 |              9 |
 module-a/src/util/ |      100 |      100 |      100 |      100 |                |
  SomeClass.js      |      100 |      100 |      100 |      100 |                |
 module-b/src/      |       75 |      100 |        0 |       75 |                |
  ModuleB.js        |       75 |      100 |        0 |       75 |              9 |
 module-b/src/util/ |      100 |      100 |      100 |      100 |                |
  SomeOtherClass.js |      100 |      100 |      100 |      100 |                |
--------------------|----------|----------|----------|----------|----------------|
All files           |    83.33 |      100 |       50 |    83.33 |                |
--------------------|----------|----------|----------|----------|----------------|

[janaz]

I have a similar issue. In my case jest 12.0.2 is also working fine in OSX, but fails to run any test inside a Docker container (ubuntu-16.04). The last working version was 11.0.2.

[cpojer]

Is there an easy way to reproduce this kind of environment so I can fix this? :)

[cpojer]

Can you try to change https://github.com/facebook/jest/blob/master/packages/jest-haste-map/src/index.js#L296 to do maxWorkers <= 1 instead and see if it works?

[janaz]

Thanks @cpojer. I'm going to try changing this file. If it doesn't help I'll provide instructions on how to reproduce it.

[janaz]

I can confirm that changing the line 296 to maxWorkers <= 1 fixed my issue

[cpojer]

I published a PR with this fix and will try to ship a new version of Jest sometime this week when I have overcome my jetlag and I'm sure I won't be doing anything silly ;) I suggest using the patch provided or downgrading to 11.0.2 for now until 12.0.3 is out sometime later this week.

[cpojer]

Ah, I'll keep it open until I publish the new version :)

[janaz]

@StephanBijzitter: Does the fix solves your issue as well?

[janaz]

I think the proper fix should be around those lines: https://github.com/facebook/jest/blob/master/packages/jest-cli/src/jest.js#L41-L42

When os.cpus().length is 1, the options.maxWorkers will be set to 0.

Thanks to the above method, I realised that a workaround can be applied by specifying the -w param in the command line: ./node_modules/.bin/jest -w 1

[StephanBijzitter]

@janaz It seems then that this issue is a duplicate of #87 and this is a regression, instead of a new bug.
@cpojer unit/integration testing should definitely cover this scenario.

I will have an open-source example of this soon-ish, but the pull request indeed does fix my issue. I guess until then "jest-cli": "^12.0.3 || 11.0.2" will suffice!

Edit: 11.0.2 does nothing at all, with or without --maxWorkers 1
Edit: With --runInBand as stated below it does work indeed :-)

[ColCh]

Same error on our Ubuntu CI server.
Solved with a flag --runInBand, passed to jest.

Thank you guys for this issue, it helped me 👍

[cpojer]

THis should be fixed.