Every codebase I've inherited has a /fixtures or /mocks folder. Inside: hundreds of JSON files, half of them stale, most of them lying about the shape your real API returns.
I've spent more time updating JSON fixtures than I care to admit. Three months ago I stopped entirely and switched to a mock server driven by our OpenAPI spec. I haven't touched a fixture file since.
Why fixtures fail you
When a backend engineer adds a field or renames a property, your fixtures don't know. Your tests still pass — against the old, wrong shape. The bug shows up when you integration-test against the real API, or worse, in production.
The core issue is that fixtures are a copy of your API's shape, maintained by hand, with no automatic synchronization.
The alternative: spec-driven mocking
If you have an OpenAPI spec (and you should — it's the foundation of any well-documented REST API), a mock server can read it and serve live HTTP responses that match your schemas exactly. No manual copying. No drift.
I use moqapi.dev for this. Import a spec URL or file, get a hosted mock endpoint back in under 10 seconds. Every route in the spec becomes callable immediately.
When the spec updates — which it does constantly at the start of a project — I re-import. The mock updates. Zero manual work.
The concrete workflow
# Your mock base URL after import
NEXT_PUBLIC_API_URL=https://moqapi.dev/api/invoke/mock/<your-id>
# In production:
NEXT_PUBLIC_API_URL=https://api.yourapp.com
Your API client code doesn't change. You swap one environment variable on launch day.
What you get for free
Beyond eliminating fixtures, a spec-driven mock server gives you:
Schema-accurate data — field types, formats, enum values all match your spec
Error responses — the mock can return your spec-defined 4xx/5xx schemas
Versioning — every spec version is stored and rollback-able
Chaos testing — inject random errors to build resilient error states
The spec is the source of truth. Let the tooling honor it.
Top comments (0)