HTTP Mock Testing in NodeJS

HTTP Mock Testing in NodeJS

HTTP mock tests let you implement and test a feature even if dependent services are not implemented yet. Also, you can test services that have already been implemented without actually calling those services—in other words you can test them offline. You need to analyze your business needs for that application first, and write them as scenarios in your design documents.

Let's say that you are developing a NodeJS client API for a media client that is a service (there is no such service in real life, just for testing) for music, video, pictures, etc. There will be lots of features in this API, and there might be a need for some changes from time to time.

If you have no tests for this API, you will not know what problems it will cause. However, if you have tests for this API, you can detect issues by running all the tests you have written before. If you are developing a new feature, you need to add specified test cases for that. You can find an API that's already been implemented in this GitHub repository. You can download the project and run npm test in order to run all the tests. Let’s continue the test part.

For an HTTP mock test, we will use nock, which is an HTTP mocking and expectations library for NodeJS. In HTTP mock testing, you can apply the following flow:

Define a Request/Response mock rule.

Create a test and use your function in the test.

Compare the expected results with the actual results in the test callback.

Simple Testing

Let's think about a media client API. Let's say you call the function musicsList by using an instance of the Media library as below:

In this case, you will get a music list in the response variable by making a request to https://ap.example.com/musics inside this function. If you want to write for this, you need to mock requests in order to make your tests run offline. Let's simulate this request in nock.

describe('Musics Tests', function() ..... is for grouping your tests. In the above example, we are grouping music related tests under the same group. it('should list music', function(done).... is for testing specific actions in music-related functions. In each test, the done callback is provided in order to check the test result inside the callback function of the real function. In the mock request, we assume that it will respond OK if we call the musicList function. The expected and actual result is compared inside the callback function.

Matching From a File

You can define your request and response data inside a file. You can see the below example for matching response data from a file.

When you make a request to https://api.example.com/musics with a header Content-Type: application/json, it will be intercepted by the nock HTTP mock above, and you will be able to test the expected and actual result. You can also test response headers in the same way just by stating the response header in the reply section:

HTTP Operations

When you try to delete music with id 1, it will respond 404. You can compare your actual result with 404 to check the test status. Also you can use GET, POST, DELETE, PATCH, PUT, and HEAD in the same way.

Response Repetition

Normally, mock requests made by using nock are available for the first time. You can make it available as much as you want like this:

Scope Filtering

Scope filtering becomes important when you want to filter the domain, protocol, and port for your tests. For example, the below test will let you mock requests that have sub-domains like API0, API1, API2, etc.

Turn Mocking On or Off

In test cases, you can enable real HTTP requests by setting allowUnmocked as true. Let's look at the following case:

it('should request performed to "http://api.example.com"', function(done) {
var scope = nock('http://api.example.com', {allowUnmocked: true})
.get('/musics')
.reply(200, 'OK');
http.get('http://api.example.com/musics'); // This will intercepted by the nock
http.get('http://api.example.com/videos'); // This will make real request to service
})

In a nock scenario, you can see a scenario for the /musics URI, but also if you make any URL different from /musics, it will be a real request to the specified URL instead of a failing test.

Other Utilities

We have covered how to write scenarios by providing a sample request, response, header, etc., and checking the actual and expected result. You can also use some expectation utilities like isDone(), clear the scope scenario with cleanAll(), use a nock scenario forever by using persist(), and list pending mocks inside your test case by using pendingMocks().

isDone()

Let's say that you have written a nock scenario and execute a real function to a test scenario. Inside your test case, you can check whether the written scenario is executed or not as follows:

cleanAll()

If you use a nock scenario with persist(), it will be available forever during the execution of your test. You can clear the scenario whenever you want by using this command as shown in the following example:

matching GET http://api.example.com:80/musics to GET http://api.example.com:80/musics: true

Quick Tips

Sometimes, you need to disable mocking for specific URLs. For example, you may want to call the real http://tutsplus.com, instead of the mocked one. You can use:

nock.nock.enableNetConnect('tutsplus.com');

This will make a real request inside your tests. Also, you can globally enable/disable by using:

nock.enableNetConnect();
nock.disableNetConnect();

Note that, if you disable net connect, and try to access an unmocked URL, you will get a NetConnectNotAllowedError exception in your test.

Conclusion

It is best practice to write your tests before real implementation, even if your dependent service is not implemented yet. Beyond this, you need to be able to run your tests successfully when you are offline. Nock lets you simulate your request and response in order to test your application.