Import test cases, for the file that gets uploaded twice

The rerun is the single most valuable case in this set because it is what real users do. An import of a thousand rows reports forty failures, the user fixes those forty in the original spreadsheet, and uploads the whole file again, because that is the obvious thing to do. An importer that inserts rather than matching on a stable key now has 960 duplicates and no way to tell which is which. Making the import idempotent on a business key turns the natural behaviour into the safe behaviour, and it is far more effective than telling users to upload only the failed rows.

CSV parsing is deceptively hard and the failures are silent. A delimiter inside a quoted field shifts every subsequent column, so the row lands with the right number of values in the wrong places and nothing validates as broken. A line break inside a quoted notes field turns one logical row into two physical lines, so the count reported disagrees with the file. A byte order mark attaches itself to the first header name, so a required column appears absent for reasons the user cannot see. None of these produce a parse error; they produce wrong data.

Type coercion is where identifiers get destroyed permanently. A postcode with a leading zero, a long account number, a product code that looks numeric: coerced to a number, the zero disappears and anything long enough is rounded into scientific notation. Dates have the same shape of problem in a different guise, since 03/04/2026 means two different days and guessing per row will produce a file where some dates are right and some are not. The fix in both cases is to state the format and store as text rather than infer.

Finally, the operational cases. A large import has to stream rather than load the whole file, because loading it into memory works in testing and fails at exactly the size a real customer uploads. It has to run asynchronously with progress, because a synchronous import will exceed a request timeout and leave the user with no idea what happened. And it needs a dry run, because catching a mapping error before writing ten thousand rows is worth considerably more than any amount of error reporting afterwards.