Since stumbling into this process while trying to improve NYC's performance, I have continued to discover ways that coverage data can answer questions beyond "is it tested?".
I think it would be really interesting to add a new profile command.
The signature would be:
nyc profile <profiled-dependency> <command ...>
It would not add coverage for the local library, but the dependency.
Assume some module uses AVA as it's test runner:
$ nyc profile ava ./node_modules/.bin/ava test/*.js
This executes ava ./node_modules/.bin/ava test/*.js using NYC's spawn-wrap goodness, but instead of excluding node_modules, our require hook hooks everything in node_modules/ava/ (but not node_modules/ava/node_modules).
This basically turns nyc into a quick and dirty profiling tool, allowing you to identify hot loops in your code and identify lines that are only used by your test suite.
Since stumbling into this process while trying to improve NYC's performance, I have continued to discover ways that coverage data can answer questions beyond "is it tested?".
I think it would be really interesting to add a new
profile
command.The signature would be:
It would not add coverage for the local library, but the dependency.
Assume some module uses AVA as it's test runner:
This executes
ava ./node_modules/.bin/ava test/*.js
using NYC's spawn-wrap goodness, but instead of excluding node_modules, our require hook hooks everything innode_modules/ava/
(but notnode_modules/ava/node_modules
).This basically turns
nyc
into a quick and dirty profiling tool, allowing you to identify hot loops in your code and identify lines that are only used by your test suite.