Test-PSBuildPester coverage threshold math truncates every percentage to zero

[tablackburn]

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:

1. The printed per-counter report always shows 0.00% (or 100.00%) regardless of real coverage
2. The CodeCoverageThreshold comparison ($_.percent -lt $CodeCoverageThreshold) fails for any nonzero threshold unless coverage is exactly 100% — so consumers who set, say, 0.8 get 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

[tablackburn]

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.7996 up to 0.80 would let a 0.80 threshold 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.01 must pass and 0.99 must 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, where 95 -lt 0.99 would 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: $total is 0 if a JaCoCo counter ever reports missed="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.