CSV looks simple until a real customer uploads a file exported by a spreadsheet, accounting package, or marketplace. The safest debugging move is to preserve the original bytes and reduce the failure to the smallest file that still breaks. Opening and saving the file in Excel before investigating can silently change encoding, quoting, dates, and leading zeros.
Begin with encoding and delimiters. UTF-8 with a byte-order mark is common, but so are legacy regional encodings. A semicolon-delimited file may be valid for a locale where commas are decimal separators. Detecting a delimiter from the first line alone is risky because the first field may contain quoted punctuation. Sample several complete records and let the user confirm when detection is ambiguous.
Then test quoted fields. A field may contain commas, line breaks, or escaped quote characters, so parsing line by line is incorrect. Use a mature CSV parser and configure its escape behavior explicitly. Keep blank fields distinct from missing columns: a,,c has three columns, while a short row may indicate damaged input. Report the physical row and logical record when multiline fields are allowed; otherwise an error on “line 14” is hard to find.
Dates and identifiers need separate treatment. 03/04/2026 is ambiguous without a declared locale. SKU values such as 00124 must not be converted to numbers, and long order IDs can lose precision in spreadsheet software. Define a schema per column and keep the raw string alongside the parsed value until validation succeeds.
For a regression fixture, include a BOM, non-ASCII names, an embedded newline, escaped quotes, an empty final field, a leading-zero identifier, and a malformed row. Assert both the accepted records and the exact error message. That fixture is more valuable than a parser test made only from clean, hand-written examples.