API Mocking and Data Generation Strategies for Frontend Testing
These libraries address the challenge of developing and testing frontend applications without relying on a live backend. They fall into three main categories: request interception tools that mock network responses directly in the code (msw, nock, axios-mock-adapter), server simulators that spin up a fake REST API (json-server, miragejs), and data generators that create realistic fake data for UI population (faker). Choosing the right tool depends on whether you need browser-level fidelity, Node.js test environment support, or rapid prototyping capabilities.
Npm Package Weekly Downloads Trend
Github Stars Ranking
Stat Detail
API Mocking and Data Generation Strategies for Frontend Testing
Building modern web applications often means working before the backend is ready, or testing components without hitting real APIs. The tools axios-mock-adapter, faker, json-server, miragejs, msw, and nock solve this problem in different ways. Some mock the network layer, some spin up fake servers, and others generate the data itself. Let's break down how they work and where they fit in your architecture.
🕸️ Network Interception: Browser vs Node
The biggest technical divide is where the mocking happens. Some tools run in the browser like real traffic, while others only work in Node.js test runners.
msw uses Service Workers to intercept requests at the network level in the browser.
- This means your app thinks it's talking to a real server.
- Works in both development and test environments.
// msw: Browser-level interception
import { http, HttpResponse } from 'msw';
import { setupWorker } from 'msw/browser';
const worker = setupWorker(
http.get('/users', () => {
return HttpResponse.json({ id: 1, name: 'Alice' });
})
);
worker.start();
nock intercepts HTTP requests at the Node.js level.
- It does not work in the browser.
- Ideal for Jest or Mocha tests running in Node.
// nock: Node-level interception
import nock from 'nock';
nock('https://api.example.com')
.get('/users')
.reply(200, { id: 1, name: 'Alice' });
axios-mock-adapter hooks directly into Axios instances.
- It bypasses the network entirely for Axios calls.
- Does not work with
fetchor other HTTP clients.
// axios-mock-adapter: Library-specific mocking
import AxiosMockAdapter from 'axios-mock-adapter';
import axios from 'axios';
const mock = new AxiosMockAdapter(axios);
mock.onGet('/users').reply(200, { id: 1, name: 'Alice' });
🖥️ Server Simulation: Real Process vs In-App
Some tools spin up an actual HTTP server, while others simulate one inside your application bundle.
json-server runs a standalone Node.js process.
- You get a real URL (e.g.,
http://localhost:3000). - Great for connecting multiple apps or manual testing.
// json-server: CLI usage
// Run in terminal: npx json-server --watch db.json
// db.json
{
"users": [
{ "id": 1, "name": "Alice" }
]
}
miragejs creates a server inside your JavaScript bundle.
- No external process needed.
- Requests are intercepted before leaving the browser.
// miragejs: In-app server
import { createServer, Model } from 'miragejs';
createServer({
models: {
user: Model
},
seeds(server) {
server.create('user', { name: 'Alice' });
}
});
🎲 Data Generation: Static vs Dynamic
Mocking responses is one thing, but generating realistic data is another. faker handles the content, while the others handle the transport.
faker (specifically @faker-js/faker) generates fake data on demand.
- Use it to seed your mocks with varied content.
- Note: The original
fakerpackage is deprecated.
// faker: Data generation
import { faker } from '@faker-js/faker';
const user = {
id: faker.string.uuid(),
name: faker.person.fullName(),
email: faker.internet.email()
};
msw, nock, and axios-mock-adapter usually return static data unless you combine them with a generator.
- You can pass functions to return dynamic values.
// msw with dynamic data
http.get('/users', () => {
return HttpResponse.json({
id: 1,
name: faker.person.fullName()
});
});
⚠️ Maintenance and Deprecation Status
Choosing a library also means choosing its future. Some of these tools have shifted maintenance status recently.
faker original package is deprecated.
- It is no longer maintained and may contain security issues.
- You must use
@faker-js/fakerfor new projects.
// ❌ Deprecated
import { faker } from 'faker';
// ✅ Recommended
import { faker } from '@faker-js/faker';
miragejs has slowed development.
- It is stable but not seeing active feature updates.
- Many teams are migrating to
mswfor long-term support.
// miragejs: Stable but consider migration
// No specific code change, but plan for potential rewrite
msw is actively maintained.
- Regular updates for new browser APIs and test runners.
- Recommended for new frontend projects.
// msw: Current standard
// Actively updated for React Testing Library, Cypress, etc.
🧪 Testing Scenarios: Unit vs Integration
The tool you pick often depends on the type of test you are writing.
Scenario 1: Unit Testing a Component
You want to test a React component that fetches data. You don't care about the network, just the render.
- ✅ Best choice:
axios-mock-adapterormsw - Why? Fast setup, isolates the component.
// axios-mock-adapter example
mock.onGet('/user/1').reply(200, { name: 'Test' });
render(<UserProfile id={1} />);
Scenario 2: End-to-End Testing
You want to test the full flow, including network errors and loading states.
- ✅ Best choice:
msw - Why? It runs in the real browser, catching issues other mocks miss.
// msw example for E2E
worker.start({ onUnhandledRequest: 'bypass' });
Scenario 3: Backend Integration Tests
You are testing a Node.js service that calls external APIs.
- ✅ Best choice:
nock - Why? It intercepts at the HTTP layer in Node, ensuring no real calls go out.
// nock example
nock('https://external-api.com').get('/data').reply(200, {});
Scenario 4: Rapid Prototyping
You need a frontend to work before the backend exists.
- ✅ Best choice:
json-server - Why? Zero code setup, just a JSON file and a command.
# json-server CLI
npx json-server --watch db.json --port 4000
📊 Summary Table
| Package | Environment | Type | Maintenance | Best For |
|---|---|---|---|---|
msw | Browser + Node | Network Interceptor | ✅ Active | Integration & E2E Tests |
nock | Node Only | Network Interceptor | ✅ Active | Backend & Node Tests |
axios-mock-adapter | Any (Axios only) | Library Hook | ✅ Active | Quick Unit Tests |
json-server | Node (CLI) | Real Server | ✅ Active | Prototyping |
miragejs | Browser | In-App Server | ⚠️ Slow | Legacy Projects |
faker | Any | Data Generator | ❌ Deprecated | Do Not Use (Use @faker-js/faker) |
💡 The Big Picture
msw is the modern standard for frontend network mocking. It bridges the gap between unit tests and real network behavior without the overhead of a separate server. If you are starting a new React, Vue, or Svelte project, this should be your default choice.
json-server remains unbeatable for speed when you just need a dummy API running locally. It requires zero code changes in your app, making it perfect for the first week of a project.
nock is the go-to for Node.js developers. If your tests run in Jest or Mocha on the server, nock provides the deepest level of control over HTTP traffic.
faker (specifically @faker-js/faker) is a utility, not a mocker. You will likely use it alongside msw or json-server to make your mock data look real.
Final Thought: Don't mix too many tools. For most frontend teams, a combination of msw for testing and json-server for local development covers 90% of needs. Avoid the deprecated faker package and be cautious with miragejs if you plan for long-term maintenance.
How to Choose: axios-mock-adapter vs faker vs json-server vs miragejs vs msw vs nock
- axios-mock-adapter:
Choose
axios-mock-adapterif your project is tightly coupled to Axios and you need a quick, lightweight way to mock requests within unit tests. It is ideal for isolating specific components without setting up a full network layer, but it locks you into the Axios ecosystem and does not test actual network behavior. - faker:
Avoid the original
fakerpackage as it is deprecated and unmaintained. Instead, choose its community fork@faker-js/fakerif you need to generate realistic fake data for forms, lists, or seeding databases. It is essential for populating UIs during development without relying on real user data. - json-server:
Choose
json-serverwhen you need a full, running REST API server for prototyping or end-to-end testing without writing backend code. It is perfect for early-stage development where the frontend team needs a persistent data store that supports standard HTTP methods like GET, POST, and PUT. - miragejs:
Choose
miragejsif you want an in-browser server that intercepts requests without needing a separate process, but be aware that maintenance has slowed. It is suitable for older projects already using it, though new projects should evaluatemswas a more actively maintained alternative for client-side mocking. - msw:
Choose
msw(Mock Service Worker) for modern frontend applications that require high-fidelity network mocking directly in the browser and Node.js. It is the best choice for integration and end-to-end testing because it uses the Service Worker API to intercept requests at the network level, matching real production behavior. - nock:
Choose
nockif you are writing backend tests in Node.js or frontend tests that run in a Node environment (like Jest). It intercepts HTTP requests at the source level in Node, making it powerful for testing server-side logic or API integrations, but it cannot run in the actual browser.
Popular Comparisons
README for axios-mock-adapter
axios-mock-adapter
Axios adapter that allows to easily mock requests
Installation
Using npm:
$ npm install axios-mock-adapter --save-dev
It's also available as a UMD build:
- https://unpkg.com/axios-mock-adapter/dist/axios-mock-adapter.js
- https://unpkg.com/axios-mock-adapter/dist/axios-mock-adapter.min.js
axios-mock-adapter works on Node as well as in a browser, it works with axios v0.17.0 and above.
Example
Mocking a GET request
const axios = require("axios");
const AxiosMockAdapter = require("axios-mock-adapter");
// This sets the mock adapter on the default instance
const mock = new AxiosMockAdapter(axios);
// Mock any GET request to /users
// arguments for reply are (status, data, headers)
mock.onGet("/users").reply(200, {
users: [{ id: 1, name: "John Smith" }],
});
axios.get("/users").then(function (response) {
console.log(response.data);
});
Mocking a GET request with specific parameters
const axios = require("axios");
const AxiosMockAdapter = require("axios-mock-adapter");
// This sets the mock adapter on the default instance
const mock = new AxiosMockAdapter(axios);
// Mock GET request to /users when param `searchText` is 'John'
// arguments for reply are (status, data, headers)
mock.onGet("/users", { params: { searchText: "John" } }).reply(200, {
users: [{ id: 1, name: "John Smith" }],
});
axios
.get("/users", { params: { searchText: "John" } })
.then(function (response) {
console.log(response.data);
});
When using params, you must match all key/value pairs passed to that option.
To add a delay to responses, specify a delay amount (in milliseconds) when instantiating the adapter
// All requests using this instance will have a 2 seconds delay:
const mock = new AxiosMockAdapter(axiosInstance, { delayResponse: 2000 });
You can restore the original adapter (which will remove the mocking behavior)
mock.restore();
You can also reset the registered mock handlers with resetHandlers
mock.resetHandlers();
You can reset both registered mock handlers and history items with reset
mock.reset();
reset is different from restore in that restore removes the mocking from the axios instance completely,
whereas reset only removes all mock handlers that were added with onGet, onPost, etc. but leaves the mocking in place.
Mock a low level network error
// Returns a failed promise with Error('Network Error');
mock.onGet("/users").networkError();
// networkErrorOnce can be used to mock a network error only once
mock.onGet("/users").networkErrorOnce();
Mock a network timeout
// Returns a failed promise with Error with code set to 'ECONNABORTED'
mock.onGet("/users").timeout();
// timeoutOnce can be used to mock a timeout only once
mock.onGet("/users").timeoutOnce();
Passing a function to reply
mock.onGet("/users").reply(function (config) {
// `config` is the axios config and contains things like the url
// return an array in the form of [status, data, headers]
return [
200,
{
users: [{ id: 1, name: "John Smith" }],
},
];
});
Passing a function to reply that returns an axios request, essentially mocking a redirect
mock.onPost("/foo").reply(function (config) {
return axios.get("/bar");
});
Using a regex
mock.onGet(/\/users\/\d+/).reply(function (config) {
// the actual id can be grabbed from config.url
return [200, {}];
});
Using variables in regex
const usersUri = "/users";
const url = new RegExp(`${usersUri}/*`);
mock.onGet(url).reply(200, users);
Specify no path to match by verb alone
// Reject all POST requests with HTTP 500
mock.onPost().reply(500);
Chaining is also supported
mock.onGet("/users").reply(200, users).onGet("/posts").reply(200, posts);
.replyOnce() can be used to let the mock only reply once
mock
.onGet("/users")
.replyOnce(200, users) // After the first request to /users, this handler is removed
.onGet("/users")
.replyOnce(500); // The second request to /users will have status code 500
// Any following request would return a 404 since there are
// no matching handlers left
Mocking any request to a given url
// mocks GET, POST, ... requests to /foo
mock.onAny("/foo").reply(200);
.onAny can be useful when you want to test for a specific order of requests
// Expected order of requests:
const responses = [
["GET", "/foo", 200, { foo: "bar" }],
["POST", "/bar", 200],
["PUT", "/baz", 200],
];
// Match ALL requests
mock.onAny().reply((config) => {
const [method, url, ...response] = responses.shift();
if (config.url === url && config.method.toUpperCase() === method)
return response;
// Unexpected request, error out
return [500, {}];
});
Requests that do not map to a mock handler are rejected with a HTTP 404 response. Since
handlers are matched in order, a final onAny() can be used to change the default
behaviour
// Mock GET requests to /foo, reject all others with HTTP 500
mock.onGet("/foo").reply(200).onAny().reply(500);
Mocking a request with a specific request body/data
mock.onPut("/product", { id: 4, name: "foo" }).reply(204);
Using an asymmetric matcher, for example Jest matchers
mock
.onPost(
"/product",
{ id: 1 },
{
headers: expect.objectContaining({
Authorization: expect.stringMatching(/^Basic /),
})
}
)
.reply(204);
Using a custom asymmetric matcher (any object that has a asymmetricMatch property)
mock
.onPost("/product", {
asymmetricMatch: function (actual) {
return ["computer", "phone"].includes(actual["type"]);
},
})
.reply(204);
.passThrough() forwards the matched request over network
// Mock POST requests to /api with HTTP 201, but forward
// GET requests to server
mock
.onPost(/^\/api/)
.reply(201)
.onGet(/^\/api/)
.passThrough();
Recall that the order of handlers is significant
// Mock specific requests, but let unmatched ones through
mock
.onGet("/foo")
.reply(200)
.onPut("/bar", { xyz: "abc" })
.reply(204)
.onAny()
.passThrough();
Note that passThrough requests are not subject to delaying by delayResponse.
If you set onNoMatch option to passthrough all requests would be forwarded over network by default
// Mock all requests to /foo with HTTP 200, but forward
// any others requests to server
const mock = new AxiosMockAdapter(axiosInstance, { onNoMatch: "passthrough" });
mock.onAny("/foo").reply(200);
Using onNoMatch option with throwException to throw an exception when a request is made without match any handler. It's helpful to debug your test mocks.
const mock = new AxiosMockAdapter(axiosInstance, { onNoMatch: "throwException" });
mock.onAny("/foo").reply(200);
axios.get("/unexistent-path");
// Exception message on console:
//
// Could not find mock for:
// {
// "method": "get",
// "url": "http://localhost/unexistent-path"
// }
As of 1.7.0, reply function may return a Promise:
mock.onGet("/product").reply(function (config) {
return new Promise(function (resolve, reject) {
setTimeout(function () {
if (Math.random() > 0.1) {
resolve([200, { id: 4, name: "foo" }]);
} else {
// reject() reason will be passed as-is.
// Use HTTP error status code to simulate server failure.
resolve([500, { success: false }]);
}
}, 1000);
});
});
Composing from multiple sources with Promises:
const normalAxios = axios.create();
const mockAxios = axios.create();
const mock = new AxiosMockAdapter(mockAxios);
mock
.onGet("/orders")
.reply(() =>
Promise.all([
normalAxios.get("/api/v1/orders").then((resp) => resp.data),
normalAxios.get("/api/v2/orders").then((resp) => resp.data),
{ id: "-1", content: "extra row 1" },
{ id: "-2", content: "extra row 2" },
]).then((sources) => [
200,
sources.reduce((agg, source) => agg.concat(source)),
])
);
History
The history property allows you to enumerate existing axios request objects. The property is an object of verb keys referencing arrays of request objects.
This is useful for testing.
describe("Feature", () => {
it("requests an endpoint", (done) => {
const mock = new AxiosMockAdapter(axios);
mock.onPost("/endpoint").replyOnce(200);
feature
.request()
.then(() => {
expect(mock.history.post.length).toBe(1);
expect(mock.history.post[0].data).toBe(JSON.stringify({ foo: "bar" }));
})
.then(done)
.catch(done.fail);
});
});
You can clear the history with resetHistory
mock.resetHistory();