Testing and Validation

A result can look reasonable and still be wrong. We test each calculator from several angles, combining repeatable automated checks with human review of the formulas, assumptions, and results.

Validation layers

No single test can tell us everything about a calculator, so we test in layers to examine it from different angles. We compare results with known-answer examples, test important boundaries and invalid entries, check relationships within the calculation that should always remain true, and use property-based testing to explore many valid combinations of inputs for unexpected behavior.

We also test the calculator beyond its underlying math. Our tests check the information sent to and returned from the calculation service, the behavior of the calculator interface, and the complete path a user takes from entering information through receiving a result. Together, these layers help us catch problems that any one type of test could miss.

Known-answer and human review

Worked examples give us a concrete way to review a calculator. For each example, we define the scenario, the expected results, and the acceptable rounding difference. These examples then become part of the calculator’s ongoing test suite so future changes can be checked against known behavior.

We make an important distinction between a result that matches the current software and a result that has been reviewed as the intended answer. Human review looks beyond whether a test passes and considers the formula, assumptions, limits, rounding, source choices, and whether the result appropriately answers the planning question the calculator was built to address.

What validation establishes

Together, these checks give us evidence that a calculator behaves consistently, handles invalid entries appropriately, preserves the relationships built into its formulas, produces reviewed example results, and works through the application as intended. When a test fails, we investigate the cause and resolve it rather than changing or removing the test simply to make the suite pass.

Testing also has limits. It cannot guarantee a real world outcome, account for every fact in a user’s situation, or make changing tax, financial, or historical data current on its own. Those areas require separate review of the calculator’s assumptions, reference data, sources, and intended use.