Percent rounding makes 99,995% cases pass the 100% threshold

[jvanoostveen]

We have a pre-commit hook and other checks to ensure 100% code coverage, but although the summary reports 100% coverage, when I take a look at the report output, I notice uncovered code.

=============================== Coverage summary ===============================
Statements   : 100% ( 42520/42520 )
Branches     : 100% ( 21031/21032 )    <-- left/right mismatch, but 100% is reported....
Functions    : 100% ( 9367/9367 )
Lines        : 100% ( 38434/38434 )
================================================================================

I tracked the issue to the following file:
https://github.com/istanbuljs/istanbuljs/blob/master/packages/istanbul-lib-coverage/lib/percent.js

When I enter the numbers above, I get 100 as output, but this is incorrect. As there is no history for this file, I can't figure out why the tmp var is calculated as such.

Maybe for a quick/workable fix, have a configuration option for nyc to check for the actual numbers being equal instead of relying on the percentage.

[coreyfarrell]

#452 moved the percent function from packages/istanbul-lib-coverage/lib/file.js to a new file but didn't change the code. Maybe the +5 should be removed from tmp = (1000 * 100 * covered) / total + 5? This way it would always round down.

I'm unlikely to have time to work on this for a while. Please modify the percent.js in your local node_modules to see if this resolves your issue (should cause it to calculate 99.99% branches). If so I would welcome a patch for this, please just make sure any testing issues are resolved (this might break some snapshot tests).

[jvanoostveen]

I now used the workaround to have nyc check the limits 'per file' instead of the total.
I'll try to look into it and provide a patch if time allows, for now, the 'per file' workaround at least saves my team some frustration (as the files should not become so large, or we would have a completely different problem 😄).