Repository navigation
Test-PSBuildPester coverage threshold math truncates every percentage to zero #138
Description
Test-PSBuildPester computes each coverage percentage like this when building its threshold report:
$percent = [Math]::Truncate([int]$_.missed + [int]$_.covered ? ...)
$percent = [Math]::Truncate([int]$_.covered / $total)[Math]::Truncate of a fractional value is 0, so $percent is 0 for any coverage below exactly 100%. Two user-facing consequences:
- The printed per-counter report always shows
0.00%(or100.00%) regardless of real coverage - The
CodeCoverageThresholdcomparison ($_.percent -lt $CodeCoverageThreshold) fails for any nonzero threshold unless coverage is exactly 100% — so consumers who set, say,0.8get a failing build even at 95% coverage
Suggested fix
Compute the ratio as a floating-point value and drop the truncation ($percent = $_.covered / $total), or round to a sensible precision. The {2:p} format string already handles percent rendering.
Notes
- Related history: Addressing Issue #61 - update CodeCoverage Output File Format to fix error #62 fixed the coverage output path/format; Tests: Test-PSBuildPester #102 added regression tests for output path/format but not for the threshold math — the fix should come with a test-first regression test in
tests/Test-PSBuildPester.tests.ps1(a subprocess scenario with partial coverage and a threshold below it must pass; a threshold above it must fail) - Found while evaluating repository-side coverage tracking; the shipped coverage measurement works, it is the report/threshold arithmetic that is wrong
Activity
chore: Track code coverage of the built module in the Pester task (#140)
tablackburn commentedon Aug 22, 2026
PR #165 is open and green on all CI legs.
Two notes on choices the issue left open:
Dropped the truncation rather than rounding. Rounding
0.7996up to0.80would let a0.80threshold be met by coverage that does not meet it — the same class of bug as the one being fixed. The raw fraction is what{2:p}and the documented.90 = 90%threshold already expect.The regression test is two-sided. A threshold of
0.01must pass and0.99must fail against the existing partial-coverage fixture. The first is the failing test for this issue; the second guards against an over-correction to a 0-to-100 scale, where95 -lt 0.99would silently disable gating again. Together they pin the value to a fraction without hardcoding the fixture's exact coverage.One adjacent thing I did not fix:
$totalis0if a JaCoCo counter ever reportsmissed="0" covered="0", which would throw a divide-by-zero mid-build. I have not seen Pester emit such a counter and did not want to widen the fix on speculation — worth a separate issue if anyone has seen it in the wild.