Had Code Coverage Previously, but now Disappeared

🐛 Bug Report

In my test suite, I normally ran all my tests and received some code coverage:

But now I updated npm and node, now my code coverage looks like this:

Reproduction

Visit the following repository: https://gitlab.com/jvanderen1/testing-react-components/-/tree/master

Then run the following commands:

npm install
npm run test:coverage

envinfo

  System:
    OS: macOS 10.15.2
    CPU: (8) x64 Intel(R) Core(TM) i7-4870HQ CPU @ 2.50GHz
  Binaries:
    Node: 12.13.1 - /usr/local/bin/node
    npm: 6.12.1 - /usr/local/bin/npm
  npmPackages:
    jest: ^24.9.0 => 24.9.0

[omgoshjosh]

First off, I want to congratulate and thank everyone working on/with jest. It’s really cool to see so much positivity and energy into something so rightfully popular. And everyone is just so dang nice!

TL;DR: My comment isn’t very useful. I’m looking for the right setup to get the best performance for local (watched, filtered, and full runs) and continuous integration environments and I think the v8 coverage provider will be the best option if I can get it to actually show the coverage.

---

So, my team is adopting jest and I am deep down the rabbit hole of investigating jest’s performance. I have read up on using --ci --maxWorkers=2 and i’m just starting to dig into the big performance difference between running the tests with and without coverage and with babel vs v8 as the “provider”.

The reason I’m commenting is because my investigation has led me here (and to https://github.com/facebook/jest/issues/9457 and https://github.com/facebook/jest/issues/9776) to find ways to mitigate or eliminate the performance issues that don’t seem to be config or operator error.

Our codebase is mostly angularJS in the process of moving to react and we’re trying to introduce jest as a way to make unit testing more commonplace for our developers. We use babel and webpack to build and prior to jest, we used karma and jasmine to spin up headless chrome and execute our tests with a full webpack build running in the headless browser. I’ve migrated all our spec files to test files and have seen mixed results with local and continuous integration (circleCI) when running jest.

We have 581 tests across 120 suites and my local results in seconds are farther below. Due to the consistency of my local results and laziness, I didn’t run the tests more than once in our CI pipeline, but i saw about a 95% increase without coverage (40 seconds locally --> 78 seconds in CI) and about a 130% increase with coverage (127 seconds locally --> 320 seconds in CI)

Generally, the times are down over karma without coverage, but if I want coverage (and I do!), the conundrum I’m currently facing is either:

1. use babel coverage because it works and just eat the 4x cost in CI test runs (3x for a full local run)
2. turning off coverage because it takes too long

Currently, 2 seems more appealing because coverage isn’t very important at dev time and even at PR or CI build time, the 4x increase doesn’t seem worth it for every circleCI run. It seems better to just manually produce coverage reports since this is just the beginning of our change in philosophy to “write more unit tests to maintain increase code coverage and quality”.

All that said, I believe if I can get the v8 coverage provider to correctly report, I think it will yield significantly better results on time.

---

no coverage, maxWorkers=50% 40, 40, 39, 38, 43 = avg 40

no coverage, maxWorkers=2 46, 39, 38, 41, 39 = avg 40.6

---

babel coverage, maxWorkers=50% 112, 97, 106, 108, 102 (86) = avg 105

babel coverage, maxWorkers=2 128, 127, 127, 127, 126 (118) = avg 127

note: 5-20 seconds to generate coverage report once tests are done running

---

v8 coverage, maxWorkers=50% 37, 36, 35, 35, 35 = avg 35.6

v8 coverage, maxWorkers=2 39, 39, 40, 40, 39 = avg 39.4

NOTE: v8 coverage does not currently work, i get unknown% (0/0)

[omgoshjosh]

@jvanderen1 apologies. I think at least one open issue is this one:

https://github.com/facebook/jest/issues/7874

So, I won’t make a new one, but I have linked my repo and the image above into that issue, which is where i think it’s more appropriate.

For context, i started writing the original comment because i was not getting coverage (so it was related to begin with), but by the time i finished a draft of the comment, i realized (as i noted in my TL;DR) that it just wasn’t a super helpful comment because the scope of my issues was much larger than just not getting coverage. So rather than scrap the results, I left the comment to record my effort/activity in case my symptoms match anyone else’s more completely.

All that said, it’s no secret that there are a plethora of issues around coverage, performance, and various environments and dependencies, many of which are blocked by an upstream dependency, duplicates, or related in some other way. So as someone who just started digging into this ecosystem, it’s difficult to parse what is or is not being tracked, what is or is not currently working, and what workarounds are necessary for the aforementioned myriad issues (46 open for “leak” and 57 open for “performance”). Consequently, it’s hard to find the right place to record the issues i’m seeing. I’m just happy that people are responsive! Even if I’m a jest noob and people give me thumbs down, lol.

And again, because I can’t help myself, I’m seriously amazed and immensely grateful for the hard work and dedication by the 1000+ people involved. Like many others, I’m just hoping to find something in one of these threads that works for me, you know?