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; books tie out across seven correlated systems |
| Determinism | Manual; easy to break accidentally | Pin a saved company by ID; everyone replays the same data |
| Schema fidelity | Your guess of the API shape | Native-shaped, following each vendor's API (approximate fidelity) |
| 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, by hand, as schemas move | Generate a new company in about a minute |
| 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.