How we tested the commission calculators

Expected results must come from an independent explanation

For each fixture, the expected answer is written explicitly and compared with the function’s returned result. A test that calculates its expected value by calling the same function again would tell us little about correctness. We also compare deterministic defaults across all sixteen tools and check that table rows have the same width as their headers.

The executed command was the Node test runner against tests/public-tools.test.js. It reported 31 passes, zero failures, zero cancellations and zero skips. This is a dated result for the code inspected during this build. It is not a continuing certification of every future change or every possible input.

Small numbers expose large classes of mistakes

A $1.00 basis at 12.50% gives an unrounded $0.125 and rounds to $0.13. Its negative mirror gives −$0.13. Three $0.05 bases at 10% produce $0.03 when rounded by line and $0.02 when combined first. These fixtures exercise ties and the rounding stage rather than merely checking multiplication on whole dollars.

Rejecting an input is part of the result

The suite rejects amounts with more than two decimal places, malformed thousands grouping, exponent notation and extra text. Rates below zero, above 100%, or with more than two decimal places are rejected. A zero rate remains a valid calculation input, but a positive sales target cannot be reached at zero commission rate.

Refund tests reject a refund larger than the original amount. Tax tests reject a supplied tax magnitude larger than the sale or a sign that contradicts a refund. These checks prevent a plausible-looking output from being produced after the program silently repaired or reinterpreted an invalid input.

A file can parse and still need review

CSV tests include semicolon separators, quoted delimiters, embedded line breaks and malformed quotes. Date checks distinguish a valid date from an ambiguous numeric date and an impossible calendar day. A file missing required recognised columns does not receive a misleading “all rows valid” count. Findings retain the original row and value so that a user can locate the problem.

Duplicate tests preserve field boundaries when building comparison keys and show both candidates. Staff matching tests require explicit aliases and reject conflicting mappings. Those checks cover the tool’s handling of supplied data; they do not prove that two matching rows are the same economic sale or that an alias identifies the right person.

Missing values should not become convenient zeros

The variance fixture contains two comparable rows, one row with missing reported commission and one with an invalid basis. Its totals include only the two comparable rows. The expected calculated amount is $40.00 and the variance −$40.00. The incomplete rows remain visible instead of quietly contributing zero to a grand total.

A period comparison with a zero baseline displays an unavailable percentage rather than Infinity. A checklist marked not applicable still requires an explanation. These examples test the language of uncertainty in the output as well as the arithmetic: the interface should say what is unknown instead of disguising it as a number.

The downloaded statement is another calculation surface

The statement fixture contains $80.00 service commission, $3.00 retail commission and a −$40.00 adjustment. Its source rows add to $43.00, and the total row must also say $43.00. The download is labelled illustrative and not a payslip. Out-of-period or invalid source records reject the statement rather than producing a partial file.

The serialization test also uses text beginning with spreadsheet formula characters. Such text is escaped in the CSV, while negative numeric amounts remain numeric. A correct on-screen amount is not enough if the file changes its meaning when opened in a spreadsheet. The exported evidence must preserve both totals and safe field interpretation.

What remains outside these 31 checks

These tests exercise calculation functions, parsing, output structure and download serialization. They do not establish that every browser interaction works, that a live provider export has the assumed meaning, that all accounting or employment obligations are met, or that a future deployment has the same code. Those questions need their own evidence.

For an independent starting point, reproduce the three-line rounding download and the ten-row journal close. Their expected values are published alongside the datasets. When a new edge case is found, add a fixture that fails for the actual defect and passes after the fix. A useful test collection grows from concrete questions, not from a large test count alone.