You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The max(hits) update assignment in Get-CoberturaClassLineSummary is exercised by no test, so the deduplication rule is pinned only for the first-entry-wins ordering and a regression to first-wins would pass the suite.
Run the Pester suite for Invoke-MSTestWithCoverage.Helpers.Tests.ps1 with code coverage over Invoke-MSTestWithCoverage.Helpers.ps1.
Inspect coverage of the max(hits) update assignment inside Get-CoberturaClassLineSummary.
Expected Behavior
Every branch of the stated deduplication contract should be pinned by a test. Get-CoberturaClassLineSummary documents max(hits) resolution for duplicate line numbers, so both orderings should be covered: the case where the first entry already carries the larger hits value, and the case where a later entry carries a strictly larger value and must overwrite it.
Actual Behavior
Only the first ordering is tested. Fixture F4 presents line 5 with hits=1 in .ctor () and hits=0 in .ctor (int), so the maximum is established by the first entry encountered and the update assignment at line 220 never executes. Coverage confirms it: new code measures 39/40 covered statements, and the single uncovered statement is that assignment. A regression that replaced max(hits) with first-entry-wins would leave the suite fully green.
Logs / Screenshots
Attached minimal logs or snippet
Snippet: new-code coverage 39/40 = 97.50%; the one uncovered statement is the max(hits) update at Helpers.ps1:220.
Impact / Severity
Blocker
High
Medium
Low
No defect in current behavior - the implementation is correct and the arithmetic oracle (79957 / 56124 / 23109 / 13472) is reproduced exactly. This is a test-adequacy gap on the headline max(hits) semantics of #441, raised in that feature's review as non-blocking finding NF-1. New-code coverage of 97.50% already clears the >= 90% floor, so no gate is failing.
Summary
The
max(hits)update assignment inGet-CoberturaClassLineSummaryis exercised by no test, so the deduplication rule is pinned only for the first-entry-wins ordering and a regression to first-wins would pass the suite.Environment
Invoke-Pester tests/scripts/vscode/Invoke-MSTestWithCoverage.Helpers.Tests.ps1 -CodeCoverage scripts/vscode/Invoke-MSTestWithCoverage.Helpers.ps1scripts/vscode/Invoke-MSTestWithCoverage.Helpers.ps1:220Steps to Reproduce
Invoke-MSTestWithCoverage.Helpers.Tests.ps1with code coverage overInvoke-MSTestWithCoverage.Helpers.ps1.max(hits)update assignment insideGet-CoberturaClassLineSummary.Expected Behavior
Every branch of the stated deduplication contract should be pinned by a test.
Get-CoberturaClassLineSummarydocumentsmax(hits)resolution for duplicate line numbers, so both orderings should be covered: the case where the first entry already carries the larger hits value, and the case where a later entry carries a strictly larger value and must overwrite it.Actual Behavior
Only the first ordering is tested. Fixture F4 presents line 5 with
hits=1in.ctor ()andhits=0in.ctor (int), so the maximum is established by the first entry encountered and the update assignment at line 220 never executes. Coverage confirms it: new code measures 39/40 covered statements, and the single uncovered statement is that assignment. A regression that replacedmax(hits)with first-entry-wins would leave the suite fully green.Logs / Screenshots
max(hits)update atHelpers.ps1:220.Impact / Severity
No defect in current behavior - the implementation is correct and the arithmetic oracle (79957 / 56124 / 23109 / 13472) is reproduced exactly. This is a test-adequacy gap on the headline
max(hits)semantics of #441, raised in that feature's review as non-blocking finding NF-1. New-code coverage of 97.50% already clears the>= 90%floor, so no gate is failing.Source
From: docs/features/potential/2026-08-10-cobertura-max-hits-update-branch-untested.md