Accuracy & Testing

Last updated March 2026

CalcOnce runs 1372+ automated tests before every deployment. No code change can reach production if any test fails. This page explains how we test, what we test, and where our expected values come from.

How We Test

Our testing process is designed to catch errors before they affect users:

1. Write the formula first. Every new calculation begins as a pure function in our centralized formula library — no UI code, no side effects. Just inputs in, outputs out.
2. Write tests with known answers. We create a minimum of three test cases with specific expected outputs, plus at least one edge case. Expected values come from authoritative sources, not from running our own code.
3. Tests must pass before the UI is built. We never build the calculator interface first and add tests later. The formula is verified before a single pixel is rendered.
4. Pre-commit hooks enforce compliance. A git pre-commit hook runs the full test suite automatically. If any test fails, the commit is rejected. No exceptions.
5. Continuous verification. When we modify any existing formula, the existing tests must continue to pass. If a formula changes, the test expectations are updated with a cited reason for the change.

What We Test

Our 1372+ tests span every category of calculator on the site. Each test verifies that our formula produces the exact expected output for a given set of inputs.

Example Test Cases

Here are representative examples of actual test cases from our suite. Each test specifies exact inputs, the expected output, and the authoritative source for that expected value.

How We Verify Against Authoritative Sources

Our expected test values are not generated by our own code. They come from independent, authoritative sources. Here is where we look for each category:

• Financial formulas: IRS published tax tables, Consumer Financial Protection Bureau (CFPB) amortization standards, and standard financial mathematics textbooks. Monetary values verified to 2 decimal places (penny precision).
• Health formulas: World Health Organization (WHO) BMI classification thresholds, Mifflin-St Jeor equations from the original 1990 peer-reviewed paper, Harris-Benedict activity multipliers, and NIH dietary reference intakes.
• Construction formulas: National Hardwood Lumber Association (NHLA) board foot standards, paint manufacturer coverage specifications, roofing manufacturer (GAF, CertainTeed) bundle calculations, and standard volumetric conversions.
• Astronomy/date formulas: NOAA Solar Calculator for sunrise/sunset times, timeanddate.com for moon phase verification, and the Gregorian calendar specification for date arithmetic.
• Math/statistics formulas: Standard mathematical definitions, NIST reference values, and established statistical methods from peer-reviewed sources.
• Unit conversions: National Institute of Standards and Technology (NIST) and International Bureau of Weights and Measures (BIPM) defined conversion factors.

Edge Case Testing

Real-world inputs are messy. Users enter zero values, negative numbers, extremely large numbers, and boundary conditions. Our test suite specifically covers these edge cases:

• Zero inputs: What happens when a user enters 0 for a loan amount, a dimension, or a weight? Our formulas handle these gracefully.
• Negative values: Where applicable (e.g., financial losses, temperature conversions), negative values produce correct results.
• Boundary values: BMI at exactly 18.5 and 25.0, tax brackets at the cutoff, leap year dates (Feb 29), and midnight timezone crossings.
• Extreme values: Very large loan amounts, very small percentages, 100-year age calculations, and multi-decade compound interest projections.
• Precision: Financial calculations must be accurate to the penny. Scientific calculations use appropriate significant figures. Trigonometric functions convert degrees to radians correctly.

What Happens When a Test Fails

Our system is designed to prevent formula errors from reaching users:

1. A developer makes a code change.
2. The pre-commit hook automatically runs all 1372+ tests.
3. If any test fails, the commit is blocked. The code cannot be saved to the repository.
4. The developer must either fix the formula to pass the existing test, or — if the test expectation itself was wrong — update the test with a cited correction from an authoritative source.
5. Only after all tests pass can the change proceed.

This means there is no window during which a broken formula is live on the site. The formula either passes verification or it does not ship.

Report an Accuracy Issue

If you find a discrepancy between our calculator output and a verified authoritative source, we want to know. Our commitment is to investigate every report and correct any confirmed errors immediately.

When reporting an issue, please include:

• Which calculator you used
• The exact inputs you entered
• The output our calculator produced
• The expected correct value and its source

Report an accuracy issue