Document how to get code coverage with QUnit CLI

[trentmwillis]

Having an easy-to-use solution for code coverage, integrated directly with the tool, is something we should explore. Istanbul is the de-facto standard for code coverage and so we should likely begin there.

I'll flesh this out with more details later, but wanted to put it on our roadmap.

[leobalter]

This is, of course, interesting, but I wonder if we should keep a small subset of responsibilities here while any coverage tool can be attached by users. This way we don't favor any specific coverage tool as well.

cc @jdalton, I would like your feedback here.

[jdalton]

I think coverage is create on its own. Folks have preferences and tying–in one solution will add to the complexity, support, and push other folks away. I dig a more focused approach (doing 1 thing well). QUnit could always have a recommended coverage path in docs but not directly tied-in.

[trentmwillis]

Circling back on this. The points above are good, though I would like for us to have a "happy path" for implementing code coverage.

After using the CLI in some of my personal projects, I'm going to suggest that Istanbul through the nyc CLI tool be our recommended path. It is super trivial to use (simply prepend nyc to the qunit command) and is well-documented.

If that seems reasonable, we can add a brief blurb to the docs site mentioning it.

[Krinkle]

@trentmwillis Sounds good to me. I'm quite used to environments that expose coverage through a debug extension at run-time (such as in PHP), or by instrumenting the needed files before reading them (e.g. the way you'd use Istanbul with Karma).

But, doing it externally with nyc actually makes a lot of sense and is also conveniently interoperable regardless of any unit test framework or entry point (e.g. grunt/npm test, qunit/mocha).