Generate (test) coverage statistics

To identify parts of our code that are not covered by tests, or dead code in practice, generating coverage reports would be helpful. Another use case is to quickly identify which parts of PDF.js are relevant when analysing an issue in a specific PDF file (this can especially be useful to new contributors).

There are multiple tools, but I have had a good experience with https://github.com/gotwarlost/istanbul. It can be integrated with Travis, and the results can be published to an external service such as coveralls, see e.g. https://coveralls.io/github/Rob--W/cors-anywhere?branch=master (integrated with https://github.com/Rob--W/cors-anywhere/commit/f9af03e76249b4dd38722b459293773ccddb6c7d).

PDF.js has different ways of execution that I know of (see gulpfile.js for more details):

• unittestcli - Runs some unit tests of PDF.js in Node.js (with minimal source changes, only with transpilation with babel, configured in gulpfile.js).
• unittest - Runs some unit tests of PDF.js in the browser (with minimal source changes, only with transpilation by babel, configured in systemjs.config.js)
• browsertest - Runs tests in browsers (we test Chrome and Firefox). This relies on the binary created by the generic build target, which uses code transpiled with babel and then bundled with webpack (configured in gulpfile.js).
• examples/node/pdf2svg.js - Can be used to trigger the SVG rendering backend on Node.js (depends on the generic build target, just like browsertest)
• as a browser extension (Firefox / Chromium), using the firefox / chromium build targets (uses a similar build process as the generic target, just with different DEFINES)

Ideally we would obtain coverage statistics for the original sources, but to start with we could also settle for coverage statistics on the generated JS files that directly run in the browser / Node.js (if it is easier).

[timvandermeij]

I don’t think anyone is working on this, so go ahead! It’s important to keep it simple for the initial patch. Since we use Gulp as our main tooling, it’s preferred to use that, but we’re also open for other suggestions. Refer to https://github.com/mozilla/pdf.js/issues/8632#issuecomment-455868037 for implementation ideas. It doesn’t require much experience with Gulp though because Gulp is a fairly simple task runner, i.e., it mostly wraps anything you would also do in an NPM script. Take a look at the Gulpfile to get some inspiration.

[timvandermeij]

Yes, feel free to work on this! We should start simple; see https://github.com/mozilla/pdf.js/issues/8632#issuecomment-455868037 for a possible approach.