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

In Martin Fowler's terms, a stub provides canned answers to calls made during a test, while a mock is set up with expectations about which calls it should receive and checks them. For most frontend testing, stubs are enough; mocks matter when you need to check how your code calls the API.

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 usually reasonable for thorough coverage.

Should mock responses match production data exactly?

Field names and types should match exactly. Values just need to be realistic; copying real production data into tests creates privacy risks. 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, such as total, current page, page size, and a has-next flag, in every response so your pagination UI has something to work with. A mock pagination response generator builds the full and partial pages for you.

What Makes a Good API Response for Testing

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; see our guide to generating test data for APIs. 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 very little. 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 No Content. A 401 means credentials are missing or invalid, so sending the user to log in makes sense; a 403 means logging in again won't help. 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; a mock HTTP status response generator gives you sample responses to start from. Include the error body too: many APIs return a JSON object with fields such as a code and a message, and RFC 9457 defines a standard problem details format. Your frontend must parse whichever one you use.

Rate limiting and timeout responses are easy to skip and painful to discover late. A 429 Too Many Requests, which RFC 6585 says may include 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. A mock API response generator or mock JSON data generator produces plausible records in seconds. They cover the happy path, so edit a few to add the empty, null, and oversized values above.

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?: In Martin Fowler's terms, a stub provides canned answers to calls made during a test, while a mock is set up with expectations about which calls it should receive and checks them. For most frontend testing, stubs are enough; mocks matter when you need to check how your code calls the API.
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 usually reasonable for thorough coverage.
Should mock responses match production data exactly?: Field names and types should match exactly. Values just need to be realistic; copying real production data into tests creates privacy risks. 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, such as total, current page, page size, and a has-next flag, in every response so your pagination UI has something to work with. A mock pagination response generator builds the full and partial pages for you.

Sources

RFC 9110 HTTP Semantics June 2022 — IETF
RFC 6585: Additional HTTP Status Codes — RFC Editor
RFC 9457 Problem Details for HTTP APIs July 2023 — IETF
Test Double — martinfowler.com