TOOL NOTES

Test your odds conversions against known pairs

A handful of fixed examples catches every conversion bug: 2.50 is +150 and 3/2. Build the golden table once and run it on every deploy.

Conversion code looks too simple to get wrong, right up until a rounding rule or a sign convention flips a price. The fix is a small table of known pairs that every deploy must reproduce exactly. Build it once, from documented examples, and it catches every future regression in seconds.

The golden table

Start with the pairs the odds converter publishes as its own examples, checked 2026-10-07. Decimal 2.50 is American +150 and fractional 3/2. American -200 is decimal 1.50. Decimal 2.00 implies 50%. A balanced board priced 1.91 on both sides implies about 52.36% each.

Add the boundary rows your code will actually meet: prices just above and below decimal 2.00, where the American formula changes sign, and an American value like +100, the smallest conventional one. Each row states the input, the expected outputs, and the precision you accept.

The rules your table enforces

The formula set is short: implied probability is 1 divided by the decimal price; fractional is the decimal minus one expressed as a ratio; American is the decimal minus one, times 100, at or above 2.00, and -100 divided by the decimal-minus-one below it. The converter documents these directly, checked 2026-10-07.

Two behaviors deserve explicit rows. The rejection rule: conventional American values are +100 or above, or -100 or below, and zero or anything between -100 and +100 is rejected. Your code should refuse those inputs the same way. And the display rule: decimal displays to four places, American to two, probabilities to two. A test that compares display strings instead of underlying values will flake on rounding.

Round-trip tests

The second half of the table is behavioral: converting forward and back should land within your stated precision. The converter's own precision note warns that rounding a displayed price and converting it back can change the last digits. So test the round trip on the unrounded value, and assert a tolerance, never an exact string.

Run it where the code changes

The table belongs in the unit suite, next to the conversion function, and it should run on every commit. When nothing changes, the table is silent; when someone touches the formatter for a new display, the table is the guardrail. Tests like these are cheap insurance, and they never sleep through a deploy.

Known pairs, boundary rows, round trips with tolerance. Conversion bugs stop at the table.