Most testers assemble test files the same way: in a hurry, the first time a feature needs one. A screenshot renamed three times, a CV from the downloads folder, a spreadsheet from another project. It works until a bug needs reproducing and nobody can say exactly which file caused it.
A small, deliberate kit fixes this. It takes half an hour to put together and serves every project afterwards.
What makes a good test file
- Known properties. You can state its exact size, type and contents without opening it.
- Stable. It is the same today as it was last month. A checksum proves it.
- Safe to share. It contains no personal or confidential information, so it can be attached to a bug report or sent to a supplier.
- Obviously a test file. Nobody will mistake it for real data.
Real documents from your own computer fail the third and fourth tests, and often the first.
The three sets
Baseline: does it work at all?
One small, valid, unremarkable file for each type the product accepts. If any of these fail, nothing else matters.
| Type | Suggested file |
|---|---|
| Document | Single-page invoice PDF |
| Word document | 50 KB DOCX |
| Image | 100 KB JPG and 100 KB PNG |
| Spreadsheet | Customers CSV, 100 rows and orders XLSX |
| Data | Users JSON |
| Video | Six-second MP4 |
Boundary: where are the limits?
For each documented limit, one file either side. The size index lists every exact size available. A typical set for a product with a 5 MB limit:
If the product limits image dimensions, the download page of each image sample lists its width and height.
Edge cases: what did nobody think of?
This is the set that finds bugs.
- The zero-byte file
- A file without an extension
- File names with spaces, non-ASCII characters and 120 characters
- A double extension
- CSV with quoted fields and line breaks, a semicolon delimiter and a byte order mark
- Text in many scripts, and Windows line endings
- A transparent PNG, an animated GIF and a one-pixel image
Organising the kit
Keep the files in one folder with a predictable layout, and keep that folder in version control or shared storage so the whole team uses the same bytes.
test-files/
baseline/
boundary/
edge-cases/
CHECKSUMS.txtGenerate the checksum list once:
find . -type f ! -name CHECKSUMS.txt -exec sha256sum {} + > CHECKSUMS.txtLater, sha256sum --check CHECKSUMS.txt confirms that nothing has been changed or corrupted.
A test matrix
For a feature that handles files, a simple grid keeps coverage honest. List the files down the side and the operations across the top.
| File | Upload | Preview | Download | Delete |
|---|---|---|---|---|
| Baseline PDF | ||||
| 5 MB JPG | ||||
| Zero-byte file | ||||
| Non-ASCII file name |
Fill each cell with pass, fail or not applicable. Empty cells are untested behaviour.
Reporting a file bug
A file-related bug report needs four facts that are often left out:
- The exact file. Give its name and SHA-256 checksum, or attach it. "A large PDF" is not reproducible.
- Its size in bytes. Not "about 5 MB".
- How it was provided. File picker, drag-and-drop, paste, mobile camera or API call.
- What happened to it. Was it rejected, accepted and corrupted, or accepted and lost?
An example:
Title: Upload of exactly 1,048,576 bytes fails with a blank 413 page
File: sample-pdf-1mb.pdf (1,048,576 bytes)
SHA-256: (value from the download page)
Steps: Profile > Documents > Upload, choose the file with the file picker
Expected: accepted, since the stated limit is 1 MB
Actual: nginx 413 error page, no application message
Note: sample-pdf-500kb.pdf uploads correctlyA report like that can be reproduced on the first attempt.
Keeping the kit useful
Add a file every time a bug is found with an input you did not have. Over a few projects the edge-case folder becomes a record of everything that has gone wrong before, which is the most valuable test suite a team can own.
