Fictix vs. building your own fixtures
Hand-rolled fixtures feel free. The real bill arrives later — in drift, in incoherence, and in the bugs they let through.
The hidden cost of DIY fixtures
A JSON file is quick to write and quicker to rot. It encodes one person's mental model of one API at one point in time. It doesn't reconcile against the other systems you integrate, it drifts the moment a schema changes, and it silently stops representing reality — so tests stay green while the integration breaks.
Side by side
| Your own fixtures | Fictix | |
|---|---|---|
| Cross-system coherence | Each fixture isolated; totals don't tie | One company; every system reconciles |
| Determinism | Manual; easy to break accidentally | Seed reproduces it exactly, forever |
| Schema fidelity | Your guess of the API shape | Native-shaped, like the real API |
| Time / evolution | Frozen single moment | Advancing clock, month-end, churn |
| Ground truth for detection | You hand-label, if at all | Planted + scored on precision/recall |
| Maintenance | Engineers, forever, as schemas move | Regenerate from a seed |
| Onboarding a teammate | Read tribal knowledge | Share one publish ID |
When DIY is still fine
For a single unit test of one pure function, a literal is the right tool — we're not going to pretend otherwise. The case for Fictix is integration and detection: anything where the data has to be coherent across systems, reproducible, and labelled.
Questions
Why not just keep our JSON fixtures?
They don't reconcile across systems, drift as schemas change, and have no ground truth — so integration and detection tests built on them under-test silently.
Is Fictix overkill for unit tests?
For a single pure-function unit test, a literal is fine. Fictix earns its place in integration and detection testing where coherence, determinism and labels matter.