Checkout total test cases

Updated October 30, 2026

The total is where a form's rules meet arithmetic, so it is where many bugs end up being visible. Work out the expected total yourself, before you look at what the page says. Otherwise a wrong number that looks plausible slips by.

Build a small table of expected totals

Take the rules from the requirements and compute a few orders by hand. Say a ticket costs ₪49.95, a service fee of ₪5 is charged once per order, and students get 20% off the tickets:

Now compare. Typical mismatches and what they point to:

• 3 tickets cost ₪164.85, so the fee is charged per ticket instead of per order.
• 1 ticket for a student costs ₪43.96: the 20% was taken off the fee as well.
• If there is a promo code too, two discounts may stack when the rule says only the larger applies. See the promo code guide for the arithmetic.

Two decimals, every time

Money is shown with two decimals. Check totals that end in zero: ₪24.90 should not appear as 24.9, and ₪30 should be 30.00. Then look for the opposite problem, which comes from how computers store fractions. In JavaScript, 49.95 * 0.8 + 5 is 44.96000000000001, not 44.96. If any screen prints the raw number, you will see a long tail of digits. Look everywhere a sum appears: the total, the confirmation, the receipt or email, the order history.

Rounding at half a cent is its own trap. In JavaScript, (1.005).toFixed(2) gives "1.00", not "1.01", because 1.005 cannot be stored exactly. If prices or discounts can produce half cents, ask which rounding rule applies and test a value that lands exactly on it.

Quantity at the edges

If an order holds 1 to 10 tickets, try 0, 1, 10 and 11. Then the inputs people forget:

• 2.5: rejected, not quietly turned into 2.
• -1, an empty field, 1e1 (which some code reads as 10 and some as 1).
• A total of zero. If 0 tickets is accepted, an order for ₪0 or for the fee alone may go through.

A total that goes stale

Many forms have a "Calculate" step before "Place order". Calculate, then change something (the quantity, the discount checkbox), and place the order without calculating again. Is the order charged for what the form shows now, or for what it showed before? And does the old total stay on screen next to the new choices? Either way, the user should not be charged a number they can no longer see.

Also compare the total on screen with the amount in the confirmation. They are often computed in different places, and they drift apart under exactly the cases above.

More guides: what the server trusts · double submit · all guides