Novus Examples
Browse by purpose: find fixtures by what you are testing
The /for routes skip the format taxonomy entirely. Pick OCR, ASR, segmentation, CSV parsing, schema validation, or JWT and get the fixtures that exercise that specific thing.
Format taxonomies are how libraries are organised and not how testing works. You rarely wake up needing "a TIFF"; you wake up needing something that will break your OCR pipeline, and you do not know or care which format does that.
The /for routes invert the catalog. Instead of browsing by what a file is, you browse by what you are trying to exercise, and the library hands you the fixtures that do it.
Contents
Two ways to finish
By purpose
Start from the thing under test.
By format
Fall back to /browse when you genuinely need a format.
- 1
1. Start from the thing under test
Open /for and pick the purpose. The routes cover OCR, ASR, colourization, form testing, CSV parsing, visual diff and regression, segmentation, schema and OpenAPI validation, image enhancement, PDF editor testing, JWT and JWKS, and background removal.
Each collects fixtures from wherever they live in the format taxonomy. An OCR set will span clean scans, skewed pages, and low-contrast documents that live under Images and Documents respectively — which is exactly the cross-cutting selection you would otherwise assemble by hand.
- Twelve purpose routes covering the common testing jobs.
- Fixtures are pulled across format categories, not from one.
- Saves the manual work of assembling a cross-format test set.
- 2
2. Take the hard cases, not just the easy ones
Every purpose set includes fixtures designed to fail your tool, and those are the ones worth downloading. A skewed low-contrast scan tells you far more about an OCR pipeline than a clean one, and an intentionally invalid schema document tells you more about a validator than a well-formed one.
The temptation is to grab the tidy example, watch it work, and call it tested. Resist it: passing on the easy fixture is the baseline, not the result.
- 3
3. Read the spec sheet before you interpret a failure
Every file ships with an exact spec sheet — noise sigma, silence timestamps, form fields, encodings, seeds. When a fixture fails, the spec sheet tells you what property caused it, which turns "OCR did badly" into "OCR fails above this noise level".
That is the difference between a bug report and a shrug. A specific property to point at is what makes a failure actionable.
- 4
4. Use pairs where the purpose has a before and after
Several purposes are inherently comparative — colourization, enhancement, visual diff, segmentation — and those sets lean on paired fixtures. A clean and noisy version of the same file, or a greyscale and colour twin, makes the evaluation direct rather than impressionistic.
Because both halves come from the same deterministic generator with a known seed, the only difference between them is the property under test. Nothing else varies to muddy the comparison.
- 5
5. Fall back to /browse when you do need a format
Purpose browsing does not replace the catalog. When you genuinely need a specific format — a WOFF2 font, an ISO archive, an .mbox mailbox — /browse lists all 17 categories with their counts and gets you there directly.
The two views are the same 2,097 files seen from different angles. Use whichever matches the shape of the question you actually have.
- 6
6. Remember what a downloadable file cannot test
Some purposes are not files at all. Accessibility tooling, scrapers, and browser automation need pages that behave a particular way, which is what the twelve live targets at /targets exist for.
If your purpose involves focus traps, infinite scroll, cookie banners, or frame walking, the fixture you want is a live page rather than a download.
Browse by the question, not by the extension
Start at /for with the thing under test and take the hard fixtures rather than the tidy ones. Read the spec sheet when something fails so you can name the property that caused it. Use pairs for anything comparative, /browse when you genuinely need a format, and /targets when the thing you are testing is a page behaviour rather than a file.
Frequently asked questions
Quick answers to common questions about this topic.
What purposes are covered?
OCR, ASR, colourization, form testing, CSV parsing, visual diff and regression, segmentation, schema and OpenAPI validation, image enhancement, PDF editor testing, JWT and JWKS, and background removal.
How is this different from browsing by category?
Purpose routes pull fixtures across format categories. An OCR set will include files from Images and Documents, which is the cross-cutting selection you would otherwise assemble by hand.
Which fixtures should I actually download?
The difficult ones. Passing on a clean example is a baseline, not a result — the skewed, noisy, and intentionally invalid fixtures are what tell you where a tool stops working.
What if my purpose is not a file?
Use the twelve live targets at /targets. Focus traps, infinite scroll, cookie banners, print stylesheets, and frame walking need a live page rather than a download.