Add coverage tool #263
Add coverage tool #263
Conversation
Cherry-picked changes from 22122c4, but only for `test-runner.js`.
The lockfile was mispelled as `yarn-lock.json`, when `yarn` actually uses `yarn.lock` files. We can just ignore them altogether with the `--no-lockfile` flag.
Somewhere around @babel/*@7.8 are some weird module resolution bugs that was giving me odd errors. Upgrading fixes these. We can remove a number of dependencies from each test package, to allow module resolution to find the common dependencies in the root package.
By removing dependencies that already exist in the root package, we can greatly increase the speed of each test suite as `yarn install` has far less work to do.
Because the testrunner runs Jest separately for each subpackage, and because Jest cannot be configured to look outside of the package it is running in, we need to use `nyc` (Istanbul's CLI).
|
Wow, awesome! Sorry I just saw this. Please give me few days to review. I am not sure if there is a specific reason we have multiple projects with their own |
|
I am sorry - I completely forgot about this. I will try to review asap. |
|
This looks fine. Can you rebase? Sorry it took me a long time to get to this! I really appreciate your contribution. If you are excited about Vue jest I could really use some help on 5.0.0 for Vue 3. |
|
This PR makes e2e project's coverage report, not vue-jest itself. This PR is staled and conflicts with HEAD. |
See the coverage report by running
yarn test:e2e && yarn coverage. If you're on macOS, your browser should open automatically with the report. If you're on Linux, you'll have to open thecoverage/index.htmlmanually.I was having a hard time picturing just what our test coverage was through our custom testrunner, so I set out to add support for automated coverage collection.
Because the testrunner runs a separate Jest process inside each test subpackage, and because Jest cannot be configured to collect coverage outside the package it is running in, I had to add
nyc(Istanbul's CLI) and proxy the call to Jest through it. Then I needed to use Istanbul's API to merge the resulting coverage reports into a single summary.I removed most of the dependencies (including Jest itself) from the test subpackages, because there is not much reason to duplicate these as node module resolution has no problem finding them in the root package, and the test suites are an order of magnitude faster this way. I'm tempted to just remove all dependencies from each subpackage and just install them on the root instead, then we could eliminate the
yarn installstep altogether if we wanted. If we for some reason need to test specific dependency versions differently between test suites, we can always add dependencies back in, and this also helps us be very explicit in that circumstance.The only difference in test behaviour now that we're resolving most dependencies from the root
node_modulesis that these dependencies are now locked in the lockfile (they were before too, but that was because we were erroneously removingyarn-lock.jsoninstead ofyarn.lock; I've fixed that in this PR). This helps us have more deterministic builds, but if we don't actually want that and want to always test the latest version of each package it's simple enough to remove the lockfile and runyarn install --no-lockfilein CI.