What is the difference between a mock API and a stub?

A stub returns fixed data with no logic. A mock can verify that it was called correctly and may return different responses based on the request. For most frontend testing, stubs are enough. Mocks are more useful for integration and contract testing.

How many mock responses should I create per endpoint?

At minimum: one success case, one empty success case, and one error case. For critical endpoints like auth or payments, add edge cases for every status code the API documents. Five or six mocks per endpoint is reasonable for thorough coverage.

Should mock responses match production data exactly?

Field names and types should match exactly. Values just need to be realistic — actual production data shouldn't be used in tests for privacy reasons. Use generated fake data that follows the same format.

How do I test pagination with mock data?

Create at least three scenarios: a full page of results, a partial final page, and an empty first page. Include the metadata fields — total, page, pageSize, hasNext — in every response so your pagination UI has something to work with.

What Makes a Good API Response for Testing | Generator Collection

Shape Your Responses Around Real Contracts

A mock API response is only useful if it matches what production will actually send. That means consistent field names, the right data types, and the same nesting structure. A frontend built against a mock that returns user.name will break the moment production returns user.fullName. Treat your mock as a contract, not a placeholder.

The easiest way to keep mocks honest is to derive them from an OpenAPI or GraphQL schema. If you don't have one, write the mock first and use it as the spec. Either way, the structure should be agreed on before anyone writes a single component.

Include the Fields That Actually Break Things

Most developers mock the happy path: a list of three tidy items, all fields populated, no surprises. That catches almost nothing. The responses worth generating are the awkward ones — an empty array, a null optional field, a string that is 400 characters long, a number that is zero or negative.

Go through each field in your schema and ask what happens if it arrives empty, missing, or at its maximum length. Build mocks for each. A pagination response with zero total results, a user profile with no avatar URL, a price field returning 0.00 — these are the inputs your UI will mishandle if you haven't tested them.

Date and timestamp fields deserve special attention. Test ISO 8601, Unix timestamps, and timezone edge cases separately. Pick one format for your mock and make sure your parser handles it without silent failures.

Model Status Codes as Carefully as Response Bodies

A 200 with an empty body is different from a 204. A 401 should trigger a redirect to login; a 403 should not. If your mock server returns 200 for everything, your error-handling code never runs during development — which means it definitely runs in production, for the first time, in front of users.

Map out the status codes your API can realistically return for each endpoint and write a mock for each one. Include the error body too: most APIs return a JSON object with a code and message field on failures, and your frontend needs to parse that correctly.

Rate limiting and timeout responses are easy to skip and painful to discover late. A 429 with a Retry-After header, or a response that takes eight seconds to arrive, will reveal a lot about how your app behaves under pressure.

Keep Mock Data Realistic Without Being Precious

Mock data should look plausible enough that a developer can reason about it, but it doesn't need to be perfect. Real-looking names, realistic email addresses, and sensible numeric ranges all help. Fake data generators are good for this — they produce consistent-looking records without any manual effort.

Avoid copy-pasting the same mock object fifty times. Variation catches more bugs. If your list endpoint returns ten items, give them different field values, not the same record repeated. A component that renders fine with identical data often breaks when names have different lengths or images have different aspect ratios.

Frequently asked questions

What is the difference between a mock API and a stub?: A stub returns fixed data with no logic. A mock can verify that it was called correctly and may return different responses based on the request. For most frontend testing, stubs are enough. Mocks are more useful for integration and contract testing.
How many mock responses should I create per endpoint?: At minimum: one success case, one empty success case, and one error case. For critical endpoints like auth or payments, add edge cases for every status code the API documents. Five or six mocks per endpoint is reasonable for thorough coverage.
Should mock responses match production data exactly?: Field names and types should match exactly. Values just need to be realistic — actual production data shouldn't be used in tests for privacy reasons. Use generated fake data that follows the same format.
How do I test pagination with mock data?: Create at least three scenarios: a full page of results, a partial final page, and an empty first page. Include the metadata fields — total, page, pageSize, hasNext — in every response so your pagination UI has something to work with.