Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

jest coverage misses subprocesses #5274

Open
mnmkng opened this issue Jan 10, 2018 · 14 comments
Open

jest coverage misses subprocesses #5274

mnmkng opened this issue Jan 10, 2018 · 14 comments

Comments

@mnmkng
Copy link

mnmkng commented Jan 10, 2018

Hello,

some time ago I opened an issue with nyc, which is a CLI interface to istanbul, the instrumenter used by jest #729. It is related to getting incorrect coverage out of jest (+ nyc) combination. I'll briefly summarize and hopefully explain why I'm also opening the issue with Jest.

We use Jest as our test platform and would like to also use its --coverage feature. However, even after thorough testing, we weren't able to get coverage output for files executed in a forked subprocess (we spawn servers and hit them with requests to test their API). Parent files would report coverage correctly, while no coverage would be output for child files.

So we introduced nyc to the mix. Surprisingly, nyc would output correct coverage for the child process files, but no coverage for the parent files. Gentlemen at nyc suggested running tests twice and merging the results, but that has proven difficult for our use case.

Expected behavior

Jest should correctly output coverage for forked processes.

Observed behavior

Jest outputs no coverage for forked processes.

Repo that reproduces the issue

https://github.com/mnmkng/nyc-jest-issue

The nice gentlemen at nyc offered coordination in resolution of this issue, so feel free to refer back to the original nyc issue #729 for more details and discussion.

Thank you for your time.

@SimenB
Copy link
Member

SimenB commented Jan 19, 2018

Duplicate of #3190, but I'm fine with a tracking issue, it feels like something that should work.

@shellscape
Copy link

Huge bummer that the original issue and this one have languished for so long unresolved. Built-in coverage in jest was money in the bank, and was really hoping nyc's method for tracking coverage in subprocesses would've been migrated here. At present the only workaround is to use nyc and pretty much take jest out of the coverage game. Unfortunately that results in some pretty fugly CI setup.

@SimenB
Copy link
Member

SimenB commented Jun 19, 2018

Help very much welcome in landing support for it 🙂

I'm not sure how nyc handles it, so just digging into that and listing what would need to be done in Jest would be awesome

@chrisdothtml
Copy link

chrisdothtml commented Jan 10, 2019

@SimenB looks like nyc is using spawn-wrap (wrapper for your process and automatically wraps child processes), and require hooks to transform code for coverage during runtime.

From what I can tell, it looks like Jest is transforming everything first, then running. So I think Jest would need to switch to the hook-based approach to achieve this

@SimenB
Copy link
Member

SimenB commented Jan 10, 2019

Jest injects its own require which does JIT transpilation and instrumentation. Not sure how that plays with wrapping the spawned child

@chrisdothtml
Copy link

Hmm, maybe the only work needed is adding spawn-wrap to apply the require override to all processes, including spawned. I'm not very familiar with the Jest codebase but can look into this if it's not a top priority issue for the team

@coreyfarrell
Copy link
Contributor

As maintainer of nyc I have to advise against using spawn-wrap, there are edge cases where it fails especially with some shells in Windows. nyc 15 will soon be released and will instead use node-preload by default. My understanding is the next semver-major of jest will require node.js 8 so you will be able to use that module.

@JounQin
Copy link

JounQin commented Apr 26, 2021

Any news?

@github-actions
Copy link

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.

@github-actions github-actions bot added the Stale label Apr 26, 2022
@Bessonov
Copy link

activity

@github-actions github-actions bot removed the Stale label Apr 26, 2022
@nevir
Copy link

nevir commented Jul 19, 2022

This would be hugely helpful for functional test suites

@loreanvictor
Copy link

any news on this?

Copy link

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.

@github-actions github-actions bot added the Stale label Jan 31, 2024
@Bessonov
Copy link

comment

@github-actions github-actions bot removed the Stale label Jan 31, 2024
timokoessler added a commit to timokoessler/docker-deploy-api that referenced this issue Feb 3, 2024
Using complicated workaround because of jestjs/jest#5274
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

9 participants