Formula Verification Coverage

What this page reports

Every calculator on this site is backed by a test file that runs its actual shipped calculation engine against expected results. Those files are executed as a release gate: if one fails, or if a published calculator has no mapped test file at all, the site does not ship. This page publishes what that gate found, per calculator, so the claim can be checked rather than believed.

Coverage — 80/80 calculators have a suite — is the claim this site is willing to defend. The sitewide assertion total is reported further down for completeness, but it is a poor summary statistic and it is not the headline here: a handful of generated suites dominate it, so quoting it alone would flatter the thin pages and mislead you about the well-covered ones.

Built, tested, and maintained by Jay Sudha. See Methodology for how a calculator gets built in the first place.

How to read a row

Each case is classified by what kind of evidence it actually supplies, weakest to strongest. Where a case could plausibly sit in two categories, it is recorded as the weaker one — understating the evidence is safe, overstating it is not.

• Independent cross-check — The expected value comes from outside this site entirely — a published worked example, an official schedule, a statute, or a standard textbook formula, cited in the test file next to the case.
• Golden — The expected value was worked out by hand, with the arithmetic written into the test file so a reader can re-derive it. A number produced by calling our own engine does not count as golden.
• Boundary — Zero, negative, empty, very large, or degenerate inputs, and the rounding or threshold points where a formula changes behaviour.
• Property — An identity, reconciliation, or monotonic relationship that must hold for any admissible input — for example that a schedule closes to a zero balance, or that a bigger deposit never lowers the result.
• Structural — Output shape and type sanity: the field exists, the number is finite, no NaN, the array is the right length. Real checks, but the weakest evidence here.

A high total made mostly of structural and property cases is weaker evidence than a small total made of golden and independent ones, which is exactly why the table breaks the count out by kind instead of showing a single number.

The distribution, stated plainly

Across 80 calculators and 83 test suites there are 9,968 distinct passing assertions. Counted per calculator — a suite that legitimately covers several closely-related calculators counts toward each of them — that comes to 9,721. Neither figure is evenly distributed:

• Median: 48 cases per calculator. 39 of 80 calculators sit below it. The range runs from 14 (UAE Gratuity Calculator) to 3,622 (401(k) Calculator).
• The top 5 calculators hold 58.2% of the per-calculator total (5,656 of 9,721). Any average computed over this data is dominated by them.
• 2 suites are property-based and account for 49.6% of all distinct assertions (4,941 of 9,968): 401(k) engine, Retirement engine. These generate thousands of checks from loops over input ranges. That is genuinely useful — it explores far more of the input space than hand-written cases can — but one generated assertion is not equivalent in weight to one hand-derived expected value, and lumping them into a single sitewide number pretends otherwise.
• Case mix sitewide: 124 independent cross-check, 1,849 golden, 1,368 boundary, 4,305 property, 2,075 structural.
• 22 of 80 calculators carry at least one case checked against an outside authority rather than only against our own reasoning.

Every calculator, with its case mix

All 80 calculators, largest suite first. Every row links to the live calculator and names the test file that produced the counts. Cases marked with the strongest kinds appear leftmost.

A dash means that calculator has no case of that kind. The test files live in the project's scripts/ directory under the exact filenames shown; the repository itself is private, so the filename is given as a stable identifier you can cite or ask about through contact rather than as a public source link.

The largest suites

The 10 biggest test files, so you can see directly where the sitewide total comes from. A suite listed as generated produces its cases from loops over input ranges rather than from individually written scenarios.

What this does not prove

• It is not an independent audit. The tests were written by the same person who wrote the calculators. A case checked against an outside authority is stronger evidence than one checked against my own arithmetic, which is why those are counted separately above.
• A passing suite only proves the formula matches the cases that were chosen. It cannot prove the right formula was chosen for your situation, and it says nothing about inputs nobody thought to test.
• It is not a guarantee of a result. A lender, tax authority, or supplier applies your exact rate, fees, rounding, and local rules. Every calculator here is a planning estimate under the assumptions printed on its own page. See the Disclaimer.
• Counts are not comparable across calculators. A two-input formula can be exhaustively covered in a couple of dozen cases; an amortisation engine cannot. Read a row against what that calculator actually has to get right, not against the row above it.
• If you find a result that is wrong, the corrections process is how it gets reproduced, fixed at the formula, and re-verified.

Machine-readable version

The same data, generated by the same run, is published as JSON at /formula-verification.json so it can be cited, diffed between releases, and checked without scraping this page. It carries the generation date, the per-calculator counts and case mix, and the per-suite breakdown. It is free to cite and republish with attribution.

Both this page and that file are rendered from one generated source file. There is deliberately no second derivation path, because a trust page whose numbers drift from its own source data is worse than no page.

How the numbers get here

A single gate discovers every test file, bundles each calculator's shipped engine from source, runs the file, and reads a structured result the file writes as it goes: the calculator slug it covers, every case name, that case's kind, and whether it passed. Nothing on this page is typed in by hand, and the aggregation never re-counts or re-interprets a suite's output.

A file that runs cleanly but produces no structured result is treated as a failure and blocks the report outright, rather than quietly contributing zero. Two further cross-checks run on every regeneration: each slug a suite claims must be a genuinely live public calculator, and it must match the separate, hand-maintained release-gate inventory that maps each calculator to its test file. Any mismatch stops the report from being written at all.

Regeneration happens whenever a formula changes. The date at the top of this page is the date the run above was produced, not the date this page was last deployed.