HTTP Request Mocking Libraries Comparison
axios-mock-adapter vs fetch-mock
1 Year
axios-mock-adapterfetch-mockSimilar Packages:
What's HTTP Request Mocking Libraries?

HTTP request mocking libraries are essential tools in web development that allow developers to simulate API responses without making actual network requests. This is particularly useful for testing and development purposes, as it enables developers to create predictable and controlled environments for their applications. By using these libraries, developers can ensure that their applications behave correctly under various scenarios, such as handling different response codes, simulating network latency, and testing error handling. Both axios-mock-adapter and fetch-mock serve similar purposes but are tailored for different HTTP clients, making them valuable in different contexts.

NPM Package Downloads Trend
Github Stars Ranking
Stat Detail
Package
Downloads
Stars
Size
Issues
Publish
License
axios-mock-adapter1,778,0963,47367.9 kB862 months agoMIT
fetch-mock781,8371,291117 kB1822 days agoMIT
Feature Comparison: axios-mock-adapter vs fetch-mock

Integration

  • axios-mock-adapter:

    axios-mock-adapter is designed to work specifically with Axios, allowing you to easily mock requests made through the Axios instance. It provides a straightforward API to set up and configure mock responses, making it a natural choice for projects already using Axios.

  • fetch-mock:

    fetch-mock is built to work with the Fetch API, providing a comprehensive mocking solution for fetch requests. It allows you to intercept and respond to fetch calls, making it suitable for applications that utilize the Fetch API for network requests.

Flexibility

  • axios-mock-adapter:

    axios-mock-adapter offers a flexible way to mock various types of requests (GET, POST, PUT, DELETE) and allows for conditional responses based on request parameters. This flexibility enables developers to simulate complex scenarios and edge cases effectively.

  • fetch-mock:

    fetch-mock provides extensive options for mocking responses, including the ability to return different responses based on request headers, body content, and URL patterns. This level of detail allows for thorough testing of how applications handle various API responses.

Error Handling

  • axios-mock-adapter:

    axios-mock-adapter allows you to easily simulate error responses, such as 404 or 500 status codes, enabling you to test how your application handles failures. This is crucial for ensuring robust error handling in your application.

  • fetch-mock:

    fetch-mock also supports simulating error responses, allowing you to test how your application behaves under failure conditions. You can mock network errors, timeouts, and specific HTTP status codes to ensure comprehensive testing.

Documentation and Community Support

  • axios-mock-adapter:

    axios-mock-adapter has well-structured documentation and a supportive community, making it easier for developers to find examples and troubleshoot issues. The popularity of Axios also means that many developers are familiar with its usage.

  • fetch-mock:

    fetch-mock is also well-documented and has a growing community. Its documentation includes various examples and use cases, which can help developers quickly implement mocking in their projects.

Learning Curve

  • axios-mock-adapter:

    The learning curve for axios-mock-adapter is relatively low, especially for developers already familiar with Axios. Its API is straightforward, making it easy to integrate into existing projects without significant overhead.

  • fetch-mock:

    fetch-mock has a slightly steeper learning curve for developers new to the Fetch API, but its comprehensive documentation helps mitigate this. Once familiar, developers can leverage its powerful features for effective mocking.

How to Choose: axios-mock-adapter vs fetch-mock
  • axios-mock-adapter:

    Choose axios-mock-adapter if your project uses Axios for making HTTP requests. It integrates seamlessly with Axios, allowing you to mock requests and responses directly in your existing Axios setup, which can simplify testing and improve code maintainability.

  • fetch-mock:

    Choose fetch-mock if your project uses the Fetch API for making HTTP requests. It provides a flexible and powerful way to mock fetch calls, making it ideal for projects that rely on the native Fetch API, especially in modern web applications.

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();