Learning Objectives
By the end of this lesson you will be able to:
- Design a comprehensive test suite for financial calculation fields
- Identify the specific input values that are most likely to expose precision bugs
- Write a clear bug report for a floating-point precision defect
The Financial Tester's Mindset
When testing financial systems, every decimal place is a potential bug. A system that shows $15.999999999997 instead of $16.00 is wrong — even if the developer says "it's just floating point, it's not a real bug."
In financial software, it IS a real bug. Financial reports must be deterministically reproducible. Penny discrepancies in large systems compound over millions of transactions into significant audit failures.
Critical Input Categories for Financial Testing
Category 1: Round Money Amounts
- $1.00, $10.00, $100.00, $1000.00
- Multiplied by round percentages (10%, 25%, 50%)
- Expected: exact round results with no trailing decimals
Category 2: Fractional Amounts
- $0.01 (one cent — the smallest unit)
- $0.10, $0.25, $0.33 (fractions that can't be represented exactly in binary)
- After arithmetic operations, check for trailing noise
Category 3: Percentage Calculations
- 33.33% of $100 = $33.33 (or $33.3300000000000000001?)
- 6.5% tax on $15.99 = $1.04 (or $1.03935 before rounding?)
- Verify rounding behavior: does it round correctly?
Category 4: Accumulated Operations
- Apply a 0.1% fee 1000 times to $1.00
- Expected: $1.00 × (1.001^1000) = approximately $2.717
- Verify the accumulated result against a reference calculation
The Micro-Loan Interest Test
For a system that calculates micro-interest:
- Enter principal: $1.00
- Enter rate: 0.001% (very small)
- Check: does the result show trailing decimal noise?
If the result is $0.00001000000004 instead of $0.00001, that's a floating-point precision bug.
Writing the Bug Report
For a floating-point precision bug:
Summary: Interest calculation shows floating-point noise for small rates
Steps to reproduce:
1. Enter principal: 1.00
2. Enter rate: 0.001
3. Click Calculate
Expected: $0.00001
Actual: $0.0000100000000000001234
Root cause likely: calculation uses double arithmetic instead of BigDecimal
Severity: Medium (financial display accuracy)
Pro Tip: Always include the exact expected vs. actual values in floating-point bug reports. "Shows wrong number" is not actionable. "Shows 0.30000000000000004 instead of 0.3" immediately tells the developer what's happening.
Key Takeaways
- Financial systems require exact decimal precision — floating-point is never acceptable for money
- Test round amounts, fractions (especially 0.1, 0.01), percentages, and accumulated operations
- Document exact expected vs. actual values in bug reports
- The fix recommendation should always specify BigDecimal or integer storage