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

🛠️ Repo: Compute in-browser test coverage numbers #2883

Open
boneskull opened this issue Jun 14, 2017 · 3 comments
Open

🛠️ Repo: Compute in-browser test coverage numbers #2883

boneskull opened this issue Jun 14, 2017 · 3 comments
Labels
area: browser browser-specific area: repository tooling concerning ease of contribution status: accepting prs Mocha can use your help with this one!

Comments

@boneskull
Copy link
Contributor

boneskull commented Jun 14, 2017

We have coverage numbers, but only in Node.js. I'd like to see the coverage numbers against tests run with Karma.

Gathering coverage from Karma seems fraught with peril.

I would entertain other suggestions to improve how we run browser-based tests. My only requirement is that the tests run in a strict browser-like environment--jsdom shenanigans or Electron won't do.

@boneskull boneskull added area: browser browser-specific status: accepting prs Mocha can use your help with this one! qa labels Jun 14, 2017
@ScottFreeCode
Copy link
Contributor

I've been working on this in the multi-coverage branch.

Getting Coveralls to take reports from multiple build jobs in the same build turned out to be way easier than I thought. I wasted so many hours looking for a more complex solution because I didn't initially realize I could just apply COVERAGE=true to the whole build. That alone should increase the coverage somewhat as it will show branches taken in different Node versions; would be nice to get more such branches covered though (Windows, whatever other terminals we're handling).

After that, I looked into adding coverage to the browser runs. Here's what I found out.

  • karma-coverage can instrument the code and report on coverage for instrumented code, however...
  • karma-browserify doesn't look at the results of other preprocessors, therefore...
  • browserify-istanbul should be used to make karma-browserify instrument the code, which can then be reported upon by karma-coverage.
  • browserify-istanbul mysteriously doesn't run on anything going into the bundle that isn't in Karma's files list and given ['browserify'] on Karma's preprocessors list, so we have to add the relevant patterns to those lists even if they shouldn't be served directly.
  • After I got all that figured it, it finally worked! ...Until I tried to clean up the other false starts I'd had, use NYC as described below, and consolidate the code behind if (env.COVERAGE); then something changed and caused the current "bundle error" problems -- but I haven't been able to figure out what.
  • It is possible to override the coverage implementation for both browserify-istanbul and karma-coverage; this can be used to make browserify-istanbul use the same version of Istanbul as karma-coverage, or to make both use the same version of Istanbul as our Node CLI NYC. (This seems to work ok except for the above-mentioned issue, and removing it does not seem to resolve the above-mentioned issue.)

Feel free to pull it down locally and experiment to confirm or deny any of the above and try to fix the bundle errors.

@ScottFreeCode
Copy link
Contributor

(I should add that the multi-coverage branch is based off the CI fixes branch, for obvious reasons; the diff from master should get to be simpler once the CI fixes branch is merged, presumably...)

@ScottFreeCode
Copy link
Contributor

ScottFreeCode commented Jun 15, 2017

Found and fixed what I'd screwed up; that branch is working now (modulo Sauce flakes), so I've submitted PR #2886 for it.

@ScottFreeCode ScottFreeCode removed the status: accepting prs Mocha can use your help with this one! label Jul 5, 2017
@ScottFreeCode ScottFreeCode added the area: repository tooling concerning ease of contribution label Aug 25, 2017
@JoshuaKGoldberg JoshuaKGoldberg changed the title in-browser coverage numbers 🛠️ Repo: Compute in-browser test coverage numbers Dec 27, 2023
@JoshuaKGoldberg JoshuaKGoldberg added the status: accepting prs Mocha can use your help with this one! label Feb 6, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area: browser browser-specific area: repository tooling concerning ease of contribution status: accepting prs Mocha can use your help with this one!
Projects
None yet
Development

No branches or pull requests

3 participants