Testing HTTP Requests in Node.js Using Nock

Published on November 17, 2018


Testing HTTP Requests in Node.js Using Nock

While we believe that this content benefits our community, we have not yet thoroughly reviewed it. If you have any suggestions for improvements, please let us know by clicking the “report an issue“ button at the bottom of the tutorial.

Writing tests can be a very important part of your development cycle. Most code is easy to test, data goes in, write tests to make sure the right data comes out. Things start to get difficult when you introduce network requests. It’s easy enough to stand up an API server and writing integration tests, but what if you don’t want that much overhead or you are trying to test against a third-party API? nock has got you covered.

nock, or “network mock”, is a library for mocking HTTP server requests. It not only works great with Node’s built-in http and https requests, but also plays nice with other request libraries that use those interfaces, like superagent or axios.

Getting Started

Getting started with nock is easy, all we need to do is add it to our project. I recommend installing it as a development dependency since most likely you won’t be using it on your production site.

Via yarn

$ yarn add Jock --dev

Via npm

$ npm install nock --save-dev

Don’t forget to require it in your test script:

const nock = require('nock');

The Basics

nock works by allowing us to define mocked network requests, or interceptors.

The nock object itself will receive a hostname and then we can chain the request method (.get(), .post(), .put(), or .delete()) we want to mock to it.

When chaining the request method, we need to pass-in the URI of the endpoint as the first argument and optionally, the request body after that.

The last thing we need is to chain the mocked reply from the server. The .reply() accepts an HTTP status code as the first argument and then optionally, the response.

When we put it all together, it will look something like this:

  .post('/post', { id: '123' })
  .reply(200, { status: 'OK' });

The Interceptor

Before executing code that will make a network request that we want to test, we have to setup a mocked network request that will be used in place of the network request in your code:

  .reply(200, {
    "args": {},
    "headers": {
      "Accept-Encoding": "gzip, deflate",
      "Accept-Language": "en-US,en;q=0.9",
      "Connection": "close",
      "Cookie": "_gauges_unique_hour=1;
      _gauges_unique_day=1; _gauges_unique_month=1;
      _gauges_unique_year=1; _gauges_unique=1",
      "Host": "httpbin.org",
      "Upgrade-Insecure-Requests": "1",
      "User-Agent": "Mozilla/5.0 (X11; Linux
      x86_64) AppleWebKit/537.36 (KHTML, like
        Gecko) Chrome/70.0.3538.102 Safari/537.36"
      "origin": "",
      "url": "http://httpbin.org/get"

// Some code that GETs http://httpbin.org/get

The nock above will return successfully (200 OK) and return a payload that mimics the data that is returned by httpbin.org. All without actually making the external network request!

While we may be losing out on having a full fledged integration test, this method does speed things up substantially and means your test harness isn’t relying on the third-party service being online.

This is especially useful if your tests have to pass before code is deployed as part of your CI/CD pipeline.

Internally, nock keeps a list of these interceptors and as they are used, they are removed from the list.

The interceptors are used in the order they are created and we can define multiple interceptors that go to the same hostname and URI, but return different payloads.

Because interceptors are removed after they are used, any time we want to test a network call, we have to make sure that we have an interceptor available.

Mocking Server Errors

Sadly, a lot of APIs out there don’t include a mechanism for being able to simulate errors being returned by the API. This shortcoming usually leads to writing a bunch of happy path tests that give no indication as to how well the system will respond to network failures or errors.

Because we’re mocking the requests, it doesn’t matter if the API we’re working with can simulate errors, we can just simulate those bad requests ourselves!

Let’s say we want to test how our code handles a 5xx server error:


// Code we want to make sure handles errors...

Being able to test all our exception paths means we’re that much closer to the mythical 100% code coverage! 🦄

Happy nocking!

Thanks for learning with the DigitalOcean Community. Check out our offerings for compute, storage, networking, and managed databases.

Learn more about us

About the authors
Default avatar


Still looking for an answer?

Ask a questionSearch for more help

Was this helpful?

This textbox defaults to using Markdown to format your answer.

You can type !ref in this text area to quickly search our full set of tutorials, documentation & marketplace offerings and insert the link!

The yarn install command looks little off. Isn’t it?

Try DigitalOcean for free

Click below to sign up and get $200 of credit to try our products over 60 days!

Sign up

Join the Tech Talk
Success! Thank you! Please check your email for further details.

Please complete your information!

Featured on Community

Get our biweekly newsletter

Sign up for Infrastructure as a Newsletter.

Hollie's Hub for Good

Working on improving health and education, reducing inequality, and spurring economic growth? We'd like to help.

Become a contributor

Get paid to write technical tutorials and select a tech-focused charity to receive a matching donation.

Welcome to the developer cloud

DigitalOcean makes it simple to launch in the cloud and scale up as you grow — whether you're running one virtual machine or ten thousand.

Learn more
DigitalOcean Cloud Control Panel