A One-in-350,000 Bug: Why Fuzzing Beats Hand-Written Tests for Money Code

Key insight: if your test suite only checks the cases a human thought to write, it's not testing the cases that actually break in production.

A developer fuzzing an Indian tax-calculation engine found something that should be impossible: at one specific salary point, earning ₹52,880 more resulted in ₹10 less tax owed. Not a rounding quirk visible to the naked eye — a genuine monotonicity violation, buried in a one-in-350,000 slice of the input space. The engine had already passed every hand-written test. No CA, no filer, no code reviewer had ever landed on that exact number.

That's the real story here, and it's bigger than one tax engine.

Why hand-written tests miss this

When you write unit tests for a tax calculator, you test the obvious stuff: the bracket boundaries you know about, a few round numbers, maybe the documented edge cases from the spec. You're testing your mental model of the system, not the system itself. Floating-point rounding bugs don't respect mental models — they live in the gaps between the values you thought to check.

This is precisely the blind spot that fuzzing and property-based testing are built to expose. Instead of asserting calculate_tax(500000) == 12500, you assert an invariant that must hold for all inputs — and let a tool hammer the input space until it finds where you're wrong.

The invariant that actually matters here

For a tax engine, one obvious invariant is monotonicity: more income should never produce less tax, at least within a bracket. That's not a hardcoded example — it's a property.

1from hypothesis import given, strategies as st
2
3@given(
4    income=st.floats(min_value=0, max_value=10_000_000, allow_nan=False),
5    delta=st.floats(min_value=0.01, max_value=100_000, allow_nan=False),
6)
7def test_tax_is_monotonic(income, delta):
8    tax_low = calculate_tax(income)
9    tax_high = calculate_tax(income + delta)
10    assert tax_high >= tax_low, (
11        f"Tax decreased: income {income} -> {income+delta}, "
12        f"tax {tax_low} -> {tax_high}"
13    )

Run that with enough generated cases and a rounding discontinuity like the ₹52,880 one gets found automatically — no CA required. This is the difference between testing examples and testing properties: examples confirm what you already believe, properties go looking for what you don't know.

Floating-point is the wrong tool for the job

The deeper issue is that binary floating-point was ever used for tax math at all. 0.1 + 0.2 != 0.3 in almost every language, and once you're chaining rounding operations across brackets, rebates, and cess calculations, those tiny representation errors compound in ways that are genuinely hard to predict by inspection.javascript

// This is the kind of thing that quietly breaks tax engines

console.log(0.1 + 0.2); // 0.30000000000000004

// Multiply that imprecision through several bracket

// calculations and round at each step, and you get

// discontinuities that no human would design on purpose

1
2The fix isn't clever rounding logic — it's removing floating-point from the equation entirely. Use integer paise/cents internally, or a proper decimal type (`Decimal` in Python, `BigDecimal` in Java, `decimal.js` in JS), and only convert to display format at the boundary.
3

from decimal import Decimal, ROUND_HALF_UP

def calculate_tax(income: Decimal) -> Decimal:

# All arithmetic in exact decimal, rounding applied

# explicitly and once, at the very end

tax = income Decimal("0.20")

return tax.quantize(Decimal("0.01"), rounding=ROUND_HALF_UP)

1
2This alone eliminates an entire category of bugs — but it doesn't eliminate *logic* errors at boundaries, which is why you still need the property tests and fuzzing on top.
3
4### What I'd actually put in a code review checklist
5
6Based on this pattern, here's what's worth asking anytime you touch money, thresholds, or piecewise formulas:
7
8- **Is this value exact or approximate?** If it's currency, it should never be a raw `float`/`double`.