Strategic API Mocking: Choosing the Right Tool for Your Stack

Mocking network requests is a critical part of frontend development, but not all mocking tools are built the same. Some patch specific libraries, some replace global functions, and others intercept traffic at the network level. Choosing the wrong one can lock you into a specific HTTP client or make your tests brittle. Let's break down how axios-mock-adapter, fetch-mock, msw, and nock actually work and where they fit in your architecture.

🎯 Interception Level: Library vs. Global vs. Network

The most important difference is where these tools step in to stop the request.

axios-mock-adapter hooks directly into Axios. It replaces the internal adapter that Axios uses to send requests. If you aren't using Axios, this tool is useless to you.

// axios-mock-adapter: Tied strictly to the Axios instance
import AxiosMockAdapter from 'axios-mock-adapter';
import axios from 'axios';

const mock = new AxiosMockAdapter(axios);

mock.onGet('/users').reply(200, { data: ['Alice'] });

// This works because it goes through axios
await axios.get('/users');

fetch-mock replaces the global fetch function in your JavaScript environment. It doesn't care what library you use, as long as that library eventually calls fetch.

// fetch-mock: Replaces global fetch
import fetchMock from 'fetch-mock';

fetchMock.get('/users', { data: ['Alice'] });

// This works with native fetch or libraries wrapping fetch
await fetch('/users');
await myCustomFetchWrapper('/users');

msw (Mock Service Worker) operates at the network level using a Service Worker in the browser and a Node.js interceptor in tests. It sits between your app and the actual network, meaning your code thinks it's making a real request.

// msw: Intercepts at the network layer
import { setupWorker, rest } from 'msw';

const worker = setupWorker(
  rest.get('/users', (req, res, ctx) => {
    return res(ctx.json({ data: ['Alice'] }));
  })
);

worker.start();

// Your code remains unchanged
await fetch('/users'); 
await axios.get('/users');

nock intercepts HTTP requests at the low-level socket layer in Node.js. It is invisible to your code but only exists in the Node runtime.

// nock: Intercepts Node HTTP sockets
import nock from 'nock';

nock('https://api.example.com')
  .get('/users')
  .reply(200, { data: ['Alice'] });

// Works in Node.js environments only
await fetch('https://api.example.com/users');

🏗️ Development Experience: Tests Only vs. Local Dev

Some tools are strictly for running automated tests, while others can improve your daily coding workflow.

axios-mock-adapter and fetch-mock are typically used only in test suites. You usually wrap your test code to activate them. Using them during local development often requires manually injecting mock logic into your app, which clutters your source code.

// Typical test-only setup for axios-mock-adapter
describe('UserComponent', () => {
  it('loads users', () => {
    const mock = new AxiosMockAdapter(axios);
    mock.onGet('/users').reply(200, []);
    render(<UserComponent />);
    // ... assertions
    mock.restore();
  });
});

msw shines here because it allows you to run the exact same mocks in your local browser while you develop. You don't need to change your app code to switch between "mock mode" and "real API mode." You just start the worker.

// msw: Same handlers for dev and test
// src/mocks/handlers.js
export const handlers = [
  rest.get('/users', (req, res, ctx) => res(ctx.json([])))
];

// src/main.js (Development)
if (process.env.NODE_ENV === 'development') {
  const { worker } = require('./mocks/browser');
  worker.start();
}

nock is strictly for Node.js testing. It cannot run in a browser, so it offers no help for local frontend development in the browser window.

// nock: Strictly for Node test environments
test('fetches users', async () => {
  nock('https://api.example.com').get('/users').reply(200, []);
  await runServerSideLogic();
});

🔄 Handling Dynamic Logic and Delays

Real APIs aren't just static JSON blobs. They have delays, errors, and logic based on request bodies.

axios-mock-adapter lets you pass a function to reply to handle dynamic logic, but it is limited to the scope of Axios.

// axios-mock-adapter: Dynamic reply
mock.onPost('/login').reply((config) => {
  const { password } = JSON.parse(config.data);
  if (password === 'secret') return [200, { token: '123' }];
  return [401, { error: 'Invalid' }];
});

fetch-mock also supports dynamic functions and has built-in helpers for simulating network delays easily.

// fetch-mock: Dynamic reply with delay
fetchMock.post('/login', (url, opts) => {
  const body = JSON.parse(opts.body);
  return body.password === 'secret' ? { token: '123' } : 401;
}, { delay: 500 }); // Simulates 500ms latency

msw provides a very expressive context API (ctx) to set headers, cookies, and status codes dynamically, closely mimicking a real server response.

// msw: Rich context for dynamic responses
rest.post('/login', (req, res, ctx) => {
  const { password } = req.body;
  if (password === 'secret') {
    return res(ctx.delay(500), ctx.setCookie('auth', '123'), ctx.json({ token: '123' }));
  }
  return res(ctx.status(401), ctx.json({ error: 'Invalid' }));
});

nock is extremely powerful for complex scenarios like reply chaining or verifying that a request happened a specific number of times, which is vital for backend integration tests.

// nock: Advanced chaining and verification
nock('https://api.example.com')
  .post('/login')
  .times(2) // Expect exactly 2 calls
  .reply(200, { token: '123' })
  .post('/login')
  .reply(429, { error: 'Too Many Requests' });

⚠️ Deprecation and Maintenance Status

It is crucial to note the current status of these libraries before adopting them.

• axios-mock-adapter: Actively maintained. Safe to use for Axios projects.
• fetch-mock: The original fetch-mock package is in maintenance mode. The maintainers recommend migrating to @fetch-mock/fetch-mock (the scoped version) or considering MSW for new projects. For this comparison, we refer to the capabilities of the ecosystem, but be cautious with the legacy package name.
• msw: Highly active and becoming the industry standard for frontend mocking. Strongly recommended for new projects.
• nock: The gold standard for Node.js. Actively maintained and essential for backend testing.

Note: While fetch-mock works, the ecosystem is shifting towards msw for frontend work because msw doesn't require you to wrap your fetch calls or worry about global state leakage in complex test suites.

🌐 Environment Compatibility

Where can you actually run these?

💡 Real-World Selection Guide

Scenario 1: Legacy Project Using Axios

You have a large codebase deeply tied to Axios, and you just need to write unit tests for components quickly.

• Choice: axios-mock-adapter
• Why: It requires the least amount of refactoring. You can drop it into existing Jest/Vitest tests without changing how your app makes requests.

Scenario 2: Modern React/Vue App Starting from Scratch

You are building a new application and want to develop features against mocked APIs before the backend is ready.

• Choice: msw
• Why: You can share the mock definitions between your local development server and your CI pipeline. This ensures that if a test passes, the feature actually works in the browser with the same logic.

Scenario 3: Testing a Node.js Middleware or SSR Layer

You are writing tests for a Next.js API route or a Express server that calls external third-party APIs.

• Choice: nock
• Why: You need to ensure your server handles real HTTP nuances like headers, redirects, and connection timeouts. msw can do Node interception now, but nock has decades of edge-case handling for Node HTTP streams.

Scenario 4: Lightweight Script Testing

You have a simple Node script that uses fetch and you don't want to set up a Service Worker.

• Choice: fetch-mock (or native MockAgent in Node 15+)
• Why: Sometimes msw is overkill for a 50-line script. fetch-mock provides a quick global override without the boilerplate of setting up a worker instance.

🏁 Final Thoughts

If you are building a modern frontend application, msw is generally the best architectural choice. It treats mocking as a network concern rather than a library concern, which frees you to change your HTTP client (from Axios to Fetch to TanStack Query) without breaking your tests.

Stick with axios-mock-adapter only if you are maintaining an older Axios-heavy codebase and need a quick fix for unit tests. Use nock when you are testing server-side Node.js code where low-level HTTP control is required. Avoid relying on global patches like fetch-mock for complex applications, as they can sometimes hide bugs related to how different libraries handle the global fetch polyfill.