How I tested a calculator engine with 965 automated tests

The number that mattered most wasn't the timeline — it was the 965 automated tests that caught a floating-point bug before users ever saw it.

The problem is specific

A game calculator chains dozens of variables: per-character energy sources, same-element funneling, weapon passives, and burst costs. Most tools estimate with spreadsheets. A production calculator needs exact math across 123 characters, 14 passive types, and 6 cost levels.

Two data sources, one validator

The engine reads character data from two formats — one file per character for the UI, and an indexed file for calculations. They must stay in sync. I wrote a validator that compares 12 critical fields between them and fails the build on any deviation. It runs as a gate before every deploy.

This is what AI doesn't think to add. A model will happily generate two data files and move on. The validator exists because I knew the two would eventually drift.

The bug the tests caught

Sacrificial weapons produce fractional ability casts. The engine computed 2.3 extra casts per rotation, then some code paths truncated it and others rounded it. For certain characters, this shifted the recommended value by roughly 10% depending on evaluation order.

Snapshot tests failed on a specific team comp and exposed it. The fix was four decimal places of precision. Most calculators never catch this because they treat casts as integers — and the error is small per character but compounds across a team.

What the data shows

Position 1 for calculator-specific queries, winning a 50% click-through rate. Across all queries over the last 28 days: 18,384 impressions and 545 clicks (2.96% aggregate CTR). The calculator serves 123 characters across 7 elements.

The lesson: AI speeds up building, but the durable value lives in architecture decisions and the tests that protect them. See the ER QuickCalc product page for the full case study.