I Wasted 3 Days on Mock Data. Here's How I Fixed It in 10 Minutes

It was Tuesday afternoon, three days into a two-week sprint, and I was staring at a test suite turning red for the third time that day. Not because of a bug in my code. Because a JSON fixture file had the wrong shape.

We were building a product catalogue UI. The backend team was three days behind — perfectly normal, not their fault. Our frontend team had hand-written mock data in a /fixtures folder: user objects, product arrays, order responses. I'd spent two hours that morning updating product fixture files after the backend engineer Slack'd me: "hey, we added a required sku field and changed category to an object."

By the end of day three I'd updated fixtures six times. Each update took 20–40 minutes. The tests kept drifting because the fixtures were a manual artifact maintained by hand.

The Root Cause

Hand-written fixtures have a fundamental flaw: they're disconnected from the source of truth. Your API spec changes, your fixtures don't. Your backend adds validation, your fixtures don't reflect it. Your team grows, everyone has slightly different local fixture versions, and "works on my machine" becomes the team's unofficial slogan.

The real problem wasn't that I was slow at updating files. The problem was that fixtures were the wrong tool entirely.

What I Found

On Wednesday evening I was reading through the OpenAPI specification docs for an unrelated reason when I came across a discussion on Stack Overflow about mock servers from specs. Someone mentioned moqapi.dev as a free option. I hadn't heard of it.

Twenty minutes later I had a live mock API running from our actual OpenAPI spec. Let me walk you through exactly what I did.

Step 1: We Already Had an OpenAPI Spec (You Probably Do Too)

Our backend engineer had been writing the spec first — we just weren't using it for anything except documentation. The spec lived at /api/openapi.yaml in the backend repo. If your team doesn't have one yet, it takes about an hour to write specs for 10 endpoints and it's worth every minute for reasons beyond just mocking.

Step 2: Import Into moqapi.dev

I created a free account on moqapi.dev, navigated to Mock APIs → Import YAML (Spec), and pasted our spec URL directly from GitHub. The import took under 10 seconds.

Every endpoint in our spec — GET /products, POST /orders, GET /users/:id — became a live hosted endpoint immediately. No config. No code. The base URL was:

https://moqapi.dev/api/invoke/mock/[my-api-id]

Step 3: Point the Frontend at the Mock

I updated our .env.development and .env.test files:

# .env.development
NEXT_PUBLIC_API_URL=https://moqapi.dev/api/invoke/mock/[my-api-id]

# .env.production
NEXT_PUBLIC_API_URL=https://api.ourapp.com

Rebuilt. Every API call in the frontend now hit the mock. Product lists loaded with realistic data. The sku field was there. The category was correctly an object. Because the mock was generated from the same spec that defined those shapes.

Step 4: Delete the Fixtures Folder

This is the part that genuinely felt good. rm -rf /fixtures. Three hundred lines of stale JSON, gone. The test suite went green.

What Happened When the Backend Changed the Spec Again

Two days later, the backend engineer added another field. She updated the spec. I went to moqapi.dev, re-imported the new version (two clicks, under 5 seconds), activated the new spec version. The mocks updated. My frontend automatically got the correct data shape on the next API call.

Total time: 5 minutes. Compare to 40 minutes of fixture editing.

The Unexpected Bonus: Error States

Once I had the mock running, I enabled chaos testing — a 15% rate of 404 and 500 errors injected randomly. Our product page had been showing a blank white screen on 404. We'd never tested it because our fixtures always returned perfect data. Two hours later we had proper error boundaries, skeleton loaders, and retry buttons. Features we'd been "planning to add."

What I'd Tell Past Me

Don't write fixtures for APIs that have specs. Import the spec into a mock server and let the spec be the single source of truth. When the spec changes, the mock changes. When the mock changes, your tests catch real problems instead of fixture drift.

The moqapi.dev OpenAPI import docs have more detail on how versioning and spec rollback work — worth reading if you're managing multiple API versions.