Mutation testing pinned the rounding logic, but a separate 3p VAT bug slipped past 202 green tests

Rounding policy is only observable at a boundary. Half-up and banker's rounding return the same value for every input except one that lands exactly on a half unit. A fixture set with no half-unit inputs therefore cannot tell you which policy the code implements.

The library rounds half-up, MidpointRounding.AwayFromZero, because that is what tax authorities expect, against a .NET default of banker's rounding, according to the write-up on dev.to ^[5]. The suite had property tests and twenty-five golden scenarios with hand-calculated values across USD, JPY and KWD ^[20]. None of those scenarios contained a midpoint value ^[7]. Flipping the mode left 197 of the 202 tests entirely unmoved ^[23].

The scenario that looks like it was written for this case is 995 yen at 10 percent, which yields 99.5. ToEven takes that to 100, because 100 is the even neighbour, so both policies agree and the test discriminates nothing ^[8].

The 3p figure has the same shape. Three lines at 3.99 is 11.97 ^[21], and 3p spread over three identical lines is a penny each ^[22]. The author does not show the working, so read the per-line split as inference: for the error to scale with the item count, each line has to land on a half penny and get pushed the wrong way. That is precisely the input class the fixtures lacked ^[7].

His own stopping rule did not save him either. Fewer than three failures on an arithmetic mutation counted as a hole ^[15], and the ToEven mutation returned five, which clears that bar ^[24]. All five sat in the rounding helper's own unit tests ^[6]. Five failures cleared the numeric bar, but their concentration in a single file meant the call sites elsewhere were still unpinned. When every failure lives in one file, the coverage stops at that function's boundary rather than extending to the code that calls it.

The discount mutation is a cleaner reading of the same fault. Pull rounding out of the invoice-level discount calculation and exactly one test fails, a generic property test asserting that all decimals get rounded, because every discount scenario used a clean percentage of a clean subtotal ^[9].

The culture test is the one I would frame and hang on the wall. It swaps CurrentCulture to de-DE and tr-TR, exports CSV, asserts ^[10]. Nothing wrong with it. Then swap InvariantCulture for CurrentCulture in the export code and it still passes, because the fixture invoice totals 100, 20 and 120, and 100m.ToString() under de-DE gives "100" ^[11]. Change a unit price to 10.50 and the same mutation kills three tests ^[12]. The fixture's invoice totals were whole numbers, so there was no decimal separator to get wrong, no matter how sound the assertion was.

This is one library's suite, so 202 is not a number about your code. The transferable part is the condition. If the same process wrote the implementation and chose the inputs, and no input sits on a boundary where the implementation had to pick a policy, then the suite documents behaviour rather than constraining it. That is the author's own framing: the agent writes both halves, they pass, and what you have confirmed is that the code agrees with itself ^[17].

The domain is not incidental to the bill. HMRC and the ATO both permit tax to be rounded per line instead of on the subtotal, and when the accounting system at the other end rounds per line, the totals disagree by a penny ^[25].

The change that actually altered the outcome was procedural. By the third phase the author had the agent answer design questions on paper first, with real numbers, before code ^[18]. That puts an expected value outside the implementation, which is the only place an oracle can live.