Mock API Generator

Mocking HTTP APIs Without Slowing the Team Down

Frontend and backend teams almost never finish in lockstep. The frontend has a Figma file and three weeks to ship; the backend is still negotiating the database schema. Without mocks, the frontend either waits (kills velocity) or hard-codes data in components (creates technical debt that lasts forever). Mocks bridge the gap: stub out the API, build the UI, swap in the real implementation when the backend is ready.

This generator emits the boilerplate for three common mocking approaches.

The Three Mocking Styles

1. Axios mock (axios-mock-adapter style). Replaces Axios's adapter with one that returns predefined responses. Useful when your codebase already uses Axios and you want mocks colocated with your existing client setup. Pattern:

2. Fetch wrapper. A function that returns canned responses for specific URLs, bypassing the network. Lightweight, no library dependency.

3. Express handler. A real HTTP server you can run locally. Useful when you want to point your dev environment at http://localhost:3001 and have it Just Work for the team. Easy to dockerize and share.

Each has trade-offs: in-process mocks (1 and 2) are easy to set up but require code-level integration; the standalone server (3) is more setup but works across the whole stack including DevTools, curl, Postman, and other apps.

What Realistic Mock Data Looks Like

Bad mock data:

The UI renders, but every row looks the same, you can't tell if the table is sorting, can't see how long names overflow, can't preview the dark-mode design with realistic content density.

Good mock data:

Realistic name lengths, unicode coverage (accents, non-Latin scripts), varied dates, plausible IDs. The UI works harder against this data and you catch more layout bugs.

The generator produces data at this realism level by default, Faker.js–style locale-aware names, emails that look like emails, dates that span a reasonable range.

When Random Data Misses

Random data is great for populating a list view. It misses these scenarios:

• Empty states. Your "no results" component never renders if every request returns 10 items. Always test with empty arrays.
• Single-item states. "1 result" needs different copy than "5 results". Test both.
• Pagination boundaries. Page 1 of 1, page 1 of many, page in the middle, last page.
• Loading skeletons. Real network latency varies; simulate with a delay.
• Errors. 400 with validation messages, 401 (logged out), 403 (permission), 404 (not found), 500, network failure (offline). Each renders differently.
• Long content. A name that's 80 characters, a description that's 500 words, a list that's 1000 items.
• Localization. Right-to-left content (Arabic, Hebrew), wide characters (Chinese, Japanese), special characters that break naive HTML rendering.

For these, hand-write deterministic fixtures alongside the random ones. Random catches the 80% case; fixtures catch the 20% that bites in production.

Where Mocks Belong in the Codebase

Three common patterns:

1. Test fixtures only. Mocks live in __mocks__/ or __fixtures__/ alongside tests, used by Jest/Vitest test setup. Not used in dev. Dev uses a real (possibly local) backend.

2. MSW for both dev and tests. A single source of truth for mock responses, used in unit tests, in component stories (Storybook), and in dev via a Service Worker. Realistic, your dev environment behaves like production.

3. Standalone mock server. A small Express/Fastify server that the frontend connects to via a configurable API_URL env. Dev hits the mock; staging hits real. Pro: works with any consumer (browser, mobile dev build, integration tests in other languages). Con: separate process to manage.

For most JS projects, pattern 2 (MSW) is the modern default. For non-JS teams or polyglot environments, pattern 3 wins.

The Drift Problem

Mocks always drift from the real API. The API team adds a required field; the mock returns the old shape; the frontend works in dev and breaks in production. Mitigation:

• Contract testing (Pact, Spring Cloud Contract): both sides agree on a contract; CI runs the consumer's tests against a contract-based mock and the provider's tests against the same contract. Drift is caught.
• OpenAPI-derived mocks: generate mock responses from the OpenAPI schema. When the schema changes, mocks change. Tools: Prism, openapi-mock, msw-auto-mock.
• Periodic sync: regenerate mocks from a snapshot of the real API once a week. Cheap, manual, often good enough.

Mocking Anti-Patterns

• Mocking forever. Your tests pass, your dev environment works, but nothing has ever talked to the real backend. Allocate explicit time for end-to-end integration tests against the real (staging) backend.
• Mocks that diverge from real responses subtly. Real API returns null for missing fields; mock returns undefined or omits the key. Code that handles null works in dev, breaks on the difference. Mirror the real shape exactly.
• Hard-coded mock data inline in components. Tempting in a hurry, never gets removed. The component is now stuck to fake data; replacing it is a refactor. Always thread mocks through the same data layer (the hook, the service, the API client) you'd use for real data.
• Mocks that don't simulate latency. Production has 50-300ms response times; mocks return synchronously. Loading states, race conditions, and optimistic UI all behave differently. Add at least a small setTimeout delay.

Privacy

The generator runs entirely in the browser. Endpoint URLs, payload shapes, and any custom fields you specify never leave the tab. Open DevTools Network during generation: zero outbound requests.