jest-puppeteer
jest-puppeteer copied to clipboard
argos-ci
Code coverage
Hi,
Is there a setting to activate code coverage during puppeteer tests that is used in jest --coverage?
Thanks in advance
You can't activate coverage for E2E. It is very complicated to do because you don't have direct access to the tested code.
https://github.com/GoogleChrome/puppeteer/blob/v1.7.0/docs/api.md#class-coverage
@neoziro Why this issue is closed? There's even a library that transforms information that was output by puppeteer's API to a format consumable by Istanbul reports https://github.com/istanbuljs/puppeteer-to-istanbul
Anybody done any more digging on this? I've experimented with using the puppeteer coverage APIs a bit but haven't yet figured out how to shuttle that data from the worker thread back up to the parent so it can all be aggregated out. It still wouldn't be a perfect drop-in replacement for jest --coverage but it doesn't look like any of that system is accessible via setup or test code anyways.
@tivac on my side I will not work on it because it is not a priority feature for me. But I will be happy to make it happen in Jest Puppeteer. Any PR or help is welcome here!
I have a rough, slightly gross proof-of-concept working. Need to spend some time polishing it up to figure out why some of the covered lines info looks broken. If I can sort out the wonkiness I'll toss up a repo or gist and we can figure out if that makes sense to integrate it into jest-puppeteer.
this is really a very good feature! so please add this as soon as possible
I used the puppeteer-to-istanbul to get code coverage.
// setup.js
require('expect-puppeteer')
(async () => {
await Promise.all([
page.coverage.startJSCoverage(),
page.coverage.startCSSCoverage(),
]);
})();
then add
afterAll(async () => {
const [jsCoverage, cssCoverage] = await Promise.all([
page.coverage.stopJSCoverage(),
page.coverage.stopCSSCoverage(),
]);
pti.write([...jsCoverage, ...cssCoverage], {
storagePath: './.nyc_output',
});
});
at the end of the test suite.
I don't know if this is the correct way to do it tho...
The way I got coverage working reliably was to first set collectCoverage to false in the Jest config. Then, in Jest's globalSetup callback, I manually instrumented ExpressJS using nyc in the jest-dev-server setup command. For example:
await jestDevServer.setup({
command: 'nyc --nycrc-path nyc.integration.config.js -- yarn startExpressJs',
launchTimeout: 50000,
port: 3000,
});
The big challenge to making this work was getting the jest-dev-server to shutdown and reliably produce a clean Istanbul coverage report. Unfortunately, I learned that all of the processes need to gracefully terminate in ascending order (express, then nyc, and then finally jest-dev-server). Double unfortunately, jestDevServer.teardown() appears to do a process tree kill, which is brutal, creating race conditions that leads istanbul to intermittently produce empty coverage reports.
So, the dirty, stinkin' trick I finally settled on was to find the ExpressJS process by its listen port and kill ONLY that process by its pid in Jest's globalTeardown callback. That allows the jest-dev-server process tree to gracefully unwind from the bottom up. And this seems to reliably produce good coverage reports.
I used the npm find-process module to find the ExpressJS process by the port 3000 listen port, and I used the npm tree-kill-promise module to gracefully kill the ExpressJS process and its child processes.
Not sure how one would plow these learnings back into jest-dev-server. Perhaps 1st class coverage support is out of scope and describing the problem and a manual solution like mine in the README would be sufficient.
Oh, the humanity ...
I created a example for generating v8 coverage reports: https://github.com/cenfun/jest-puppeteer-coverage
Guys, all u need to get the coverage is to instrument your front-source code before compile, am I right?
@storenth If it's Istanbul's coverage, that's ture. But if it's V8 coverage, there's no need to instrument the source code.