The edge cases most upload features miss, and a fixture for each one.
File upload is one of those features that looks trivial in a demo and turns into a support queue in production. The happy path — pick a reasonably sized file, upload it, see it appear — is almost never where the bugs are. Here's a checklist of the cases that actually break upload features, and how to build a fixture for each.
If your limit is 25MB, don't just test 1MB and 100MB — test a file at 24.9MB, exactly 25MB, and 25.1MB. Off-by-one errors in size-limit checks (comparing with > instead of >=, or confusing MB with MiB) are extremely common. Use the text file generator's exact-byte-size mode to hit a target precisely, or the image generator's noise option to inflate an image file to a specific rough size.
An empty file is a surprisingly common crash source — code that assumes a file has at least a header row, or divides by the file's byte count somewhere. Generate a text file with a tiny target size to get close to this case.
Does your validator check the file extension, the MIME type sent by the browser, or the actual file signature (magic bytes)? Try uploading a real image renamed to .txt, and a text file renamed to .png — a validator that only checks the extension will accept the wrong one; a validator that only trusts the browser-reported MIME type can be fooled just as easily. Generate real files with our image and document generators, then rename the extension yourself to test this.
Filenames with spaces, emoji, right-to-left characters, or very long names (255+ characters) break naive path-handling code more often than you'd expect. This is easy to overlook because most developer's own test files have simple ASCII names.
If your feature supports multi-file or batch upload, test both extremes: 200 tiny files (which stresses request overhead and UI list rendering) and a handful of large ones (which stresses total payload size and timeout handling). The image generator's batch option and the JSON/CSV generator's row count are both useful for building a folder of many small fixtures quickly.
A `.pdf` file that isn't actually a valid PDF, a `.csv` with inconsistent column counts per row, a `.json` file that's almost-but-not-quite valid JSON — these test whether your parser fails gracefully or throws an unhandled exception that takes down the request.
What happens if the exact same file (by name, by hash, or both) is uploaded twice? What happens if an upload is interrupted partway and retried — does the system end up with a half-written file?
None of these require exotic tooling — they require deliberately generating the boundary case instead of whatever file happens to be sitting on your desktop. That's the entire premise behind this site's generators: pick the exact shape of fixture the test case calls for, rather than reusing whatever's convenient.