Static JSON Mocks Are Not Enough for Real UI Testing

The first users.json I ever committed was supposed to live for two days.

The backend team needed a sprint to ship the real endpoint. I was blocked. So I dropped a five-line JSON file into the project, imported it into the table component, and got back to building. Two days. No big deal.

Six months later that file was still there. It had grown to 800 lines. Three components imported it directly. One test depended on the order of its keys. The "real" endpoint had shipped months ago and nobody had migrated, because migrating now meant rewriting four screens that had quietly been built around assumptions only the fixture made true.

That users.json is the reason I'm careful about static mocks now. Not because they're bad — they're great when you respect the boundary. But the moment they cross from "temporary placeholder" into "the thing the UI is actually built against", you've stopped testing your interface and started testing a frozen lie.

Why static JSON feels good at first

Because it's fast. That's the whole pitch.

[
  { "id": 1, "name": "Alice", "role": "admin" },
  { "id": 2, "name": "Marco", "role": "editor" }
]

import users from "./users.json";

Two minutes from "I need data" to "I have data on the screen". For early visual work — laying out a card, deciding column widths, picking a font weight — this is the right tool. I still do it.

The trap is when the same shortcut becomes the workflow.

A frozen file gives you data. An endpoint gives you a boundary. Only one of those is what production looks like.

What static JSON quietly hides

A fixture file gives you exactly one scenario: a successful response with one specific payload, returned instantly. Real interfaces need a lot more than that, and most of what they need is invisible until something breaks.

1. Loaders that never run

A local file resolves in microseconds. Your skeleton flashes for one frame, then disappears. You think the loading state works. It doesn't — you just never gave it a chance to render.

Skeletons that have never seen a real wait time are the most common "looks fine in dev, broken in prod" bug I've debugged. Spinners stuck on, layouts that jump when data finally arrives, buttons that stay enabled when they shouldn't.

(There's a whole separate piece on testing the four UI states if you want the longer version of this argument.)

2. Errors that exist only in your imagination

A JSON file does not naturally return:

• 401 Unauthorized
• 403 Forbidden
• 404 Not Found
• 422 Unprocessable Entity
• 500 Internal Server Error
• a request that just hangs forever

So the if (error) branch in your component? That's vibes. You wrote it, you trust it, but you've never seen it run against a real failed response. The first time it does will be in production with a customer watching.

3. Empty states you've never seen

If your fixture always has data, you'll never notice that:

• the empty state copy says "Loading..." (yes, this happens)
• the layout collapses when the rows disappear
• a chart explodes because data[0] is undefined
• the search input has no "no results" feedback

Empty isn't an edge case — it's the default for first-time users, filtered tables, and fresh accounts. A fixture full of three Alices won't ever surface those bugs.

4. Data that's too clean to be real

Real data is messy. Names are 40 characters long. Email addresses contain pluses and dots. Some fields are null. Some statuses are values nobody told you about. Dates straddle timezones.

A handcrafted fixture is, almost by definition, the prettiest version of your data. So you don't catch:

• truncation bugs in cells
• overflow in tooltips
• sort orders that look wrong with mixed-case strings
• validation logic that assumes email is always present
• rendering that breaks when an avatar URL is null

This is the limitation that most surprises teams — because the fixture looked fine.

Generated data isn't perfect data. It has long names, missing fields, weird casing — exactly what makes a UI break in production.

5. No real boundary between UI and data

This is the quiet one, and it bites the hardest.

When a component does import users from "./users.json", the data is part of the bundle. There's no network call. No serialization. No HTTP status. No async behavior. The component thinks data is just there, synchronously, always, in the exact shape it expects.

Then the real backend ships and you discover:

• your fetching layer doesn't exist
• error handling lives nowhere
• your loading state has never been wired up
• the response shape is slightly different and twelve files care
• caching is now an unsolved problem

The "two-day fixture" turns into a two-week refactor. I've shipped this mistake. I've reviewed it in PRs. It's the most consistent way to turn a fast start into a slow finish.

Visual prototyping vs. UI testing

These are different jobs and they want different tools.

Static JSON is good for: drawing the interface. Layout decisions, component composition, design review screenshots, isolated Storybook stories.

A mock API is good for: exercising the interface. Loading, errors, empty states, network timing, retries, varied payloads, anything that depends on the wire being involved.

You usually want both. The mistake isn't using fixtures — it's expecting them to do a job they were never designed for.

A better pattern: let the UI talk to a URL from day one

Even when there's no real backend, your component should call fetch, not import.

export async function fetchUsers() {
  const response = await fetch("/api/users");

  if (!response.ok) {
    throw new Error("Failed to fetch users");
  }

  return response.json();
}

That's the whole trick. The component now lives behind an HTTP boundary, exactly like it will in production. The fact that the URL currently points at a mock instead of the real backend is irrelevant — the contract is HTTP, not "an import statement".

Six months later, when the real /api/users ships, you change one base URL. No rewrites.

Same data shape, real URL. Now your fetch layer, your error handling, and your loading states all have something to actually run against.

What real UI testing looks like

Once you're behind a real URL, the same screen can be exercised against scenarios you couldn't simulate before:

• success with realistic, varied rows
• success with zero rows
• slow success (latency that mirrors real networks)
• validation or auth failure (401, 422)
• server error (500)
• intermittent failure (fails twice, succeeds on retry)

This is where mock APIs earn their keep. Not by being faster than fixtures — they're not — but by being more honest about what production actually feels like.

When static JSON is still the right call

I don't want to oversell this. Fixtures are still the right tool when:

• you're designing a single component in isolation in Storybook
• you need deterministic data for a screenshot test or a visual regression suite
• you're building a quick prototype that nobody will mistake for the real app

The mistake is using fixtures and then forgetting to graduate. The boundary between "this is a sketch" and "this is the implementation" is exactly where teams lose six months.

Where a mock API stops being optional

The honest threshold: if your screen depends on response timing, error handling, empty states, or varied data, you've outgrown the fixture. That covers most of the screens that matter:

• dashboards
• data tables and lists
• search and filtering
• onboarding flows
• settings pages
• any CRUD interface

For these surfaces, a frozen file is no longer prototyping. It's hiding bugs.

Where Mimicry fits in

Mimicry is built for the moment static fixtures stop being enough. Instead of a JSON file living inside your bundle, you point the frontend at a real URL — same shape, same headers, same network behavior — and you control what comes back from outside the codebase.

Concretely, that means:

• a real HTTP endpoint your fetch layer can actually exercise
• generated data with realistic variety, not three handcrafted rows
• chaos mode to inject latency or failures on the same URL without touching the frontend
• CRUD resources with relations between them, something a flat JSON file can't represent at all
• guest mode, so you can spin up the first endpoint in under a minute without an account

This is the line a users.json cannot cross. The moment your data has relations, a flat file becomes a maintenance project.

The point isn't that fixtures are wrong. It's that they describe one moment of your data, and your UI has to survive a thousand of them.

Final takeaway

The cheapest thing in software is shipping a frozen file. The most expensive thing is shipping the same frozen file six months later, after the rest of the codebase has quietly been built around its assumptions.

Use fixtures for what they're good at: sketching. Switch to a real endpoint the moment the screen depends on anything beyond rendering. That single boundary — fetch instead of import — is the difference between a frontend that ships fast and a frontend that ships well.

If you're already living in a users.json you wish you could escape, you can put a real URL in front of it as a guest at Mimicry in about a minute. If you want the longer playbook, How to Mock an API for Frontend Development walks through the full setup.