TESTING

How to mock network request in Jest

Mocking network requests even easier

Photo by Taylor Vick on Unsplash

Nowadays, it is necessary to modify an older library to TS and perform unit testing. If the library is modified to TS, there is still a little bit better. Unit testing is purely a current study and sold now. For beginners to learn the Jest framework, I think the more troublesome thing in unit testing is to test network requests. So record some of the ways that Mock dropped Axios to initiate network requests. This is my 39th Medium article.

Introduction

The examples mentioned in the article are all in the jest-mock-server repository. You can start the example directly by installing the package manager, for example, installing through yarn:

$ yarn install

Some commands are specified in the package.json, which are as follows:

• npm run build : The packaging command of rollup .
• npm run test:demo1 : Simply mock the network request library encapsulated.
• npm run test:demo2 : Complete the mock by re-implement hook.
• npm run test:demo3 : Use the library in Jest to complete the implementation of demo2.
• npm run test:demo4-5 : Start a node server, proxy the network request through the proxy of axios, and forward it to the started node server. By setting the corresponding unit test request and response data, the corresponding relationship is used to realize the test, which is jest-mock-server finished work.

Here we encapsulate a layer of axios, which is closer to the real scene. You can view the test/demo/wrap-request.ts file. In fact, it simply creates an axios instance internally and forwards the response data.

The test/demo/index.ts file simply exports a counter method, where these two parameters are processed to a certain extent before the network request is initiated. Then the response data is also processed to a certain extent, just to simulate related operations.

Here Jest uses the browser environment simulated by JSDOM, the startup file test/config/setup.js is configured in the setupFiles attribute configured in jest.config.js, and JSDOM is initialized here.

demo1: Simple Mock network request

Simple mock processing is performed in test/demo1.test.js, and you can try to run it through npm run test:demo1. In fact, a mock operation is performed on the wrap-request library that wraps axios. wrap-request will be compiled when Jest is started. After the library is mocked here, all the files imported into the library afterward will get the mocked objects. In other words, we can think that this library has been rewritten, and the methods after rewriting are all JEST’s Mock Functions . You can use functions such as mockReturnValue for data simulation. For Mock Functions, please refer to this link.

Here we have completed the Mock of the return value, which means that we can control the value returned by the request in the wrap-request library. However, it was mentioned before that there are also certain processes for the incoming parameters. We haven’t made any assertions on this part of the content, so we also need to try to deal with this.

demo2: hook network request

demo2 can be tried to run through npm run test:demo2. As mentioned above, we can handle the return value but there is no way to assert whether the input parameters are processed correctly so we need to deal with this situation. Fortunately, Jest provides a way to directly implement the function library that is mocked. Therefore, Jest also provides a mockImplementation method, which is used in demo3. Here we have rewritten the mocked function library. We can also use jest.fn to complete Implementations . Here we write a hook function before returning and then implement assertions or specify return values ​​in each test. In this way, the above problem can be solved, which is actually the realization of mockImplementation of Mock Functionsin Jest.

demo3: Use Jest’s mockImplementation

demo3 can be tried to run through npm run test:demo3. The example in demo2 is actually complicated to write. In Jest, Mock Functionshas the implementation of mockImplementation which can be used directly.

demo4–5: Really initiate a network request

demo4 and demo5 can be tried to run through npm run test:demo4–5. In this way, a real data request is made. Here, axios proxy will be used to forward internal data requests to the specified server port. Therefore, the server is also started locally and the test is performed by specifying the request and response data related to the corresponding path. If the requested data is incorrect then the related response data will not be matched normally. Therefore, the request will directly return 500. If the returned response data is incorrect, it will also be captured during the assertion. In the jest-mock-server library, first, we need to specify three files which are corresponding to the three life cycles that each unit test file to be executed before startup. Jest test is executed before the three life cycles and the three life cycles are executed after the Jest test is completed. The three files which we need to specify are the setupFiles, globalSetup, and globalTeardown configuration items of the jest.config.js configuration file.

First we are going to start with setupFiles. In addition to initializing JSDOM, we also need to operate the default proxy of axios. Because the solution adopted is to use the proxy of axios to forward data requests. Therefore, it is necessary to set the proxy value at the forefront of the unit test.

Once we set up the above file inside thetest/config folder then we need to add two more files in there which are globalSetup and globalTeardown . These two files refer to the operations performed before the Jest unit test starts and after all tests are completed. We put the server startup and shutdown operations in those two files.

Please note that the file running in these two files is a separate independent contex which has nothing to do with the contex of any unit test including the file specified by the setupFiles configuration item. Therefore, all the data here is either specified in the configuration file, or It is to transmit between server ports through the network.

For the configuration port and domain name information, put it directly in the globals field in jest.config.js. For the debug configuration item, it is recommended to use it in conjunction with test.only.

Now, there may be suggestion that why the server should not be started and shut down in the beforeAll and afterAll life cycles of each unit test file. Therefore, I have tried this solution. In this solution, for each test file, the server is started and then shut down. Therefore, this solution is relatively time-consuming. But in theory, this solution is reasonable. After all, it is true that data isolation is necessary. But there is a problem when afterAll is closed. It does not actually close the server and port occupation because the close method is called when the node server is closed. WhenafterAll is closed, It just stopped processing the request but the port is still occupied. When the second unit test file is started, an exception will be thrown that the port is being used. Although I tried some solutions, they are not ideal because sometimes the port is still occupied. Especially when the node is run for the first time after it is turned on, the probability of abnormality is relatively high. Therefore, the effect is not very satisfactory. In the end, the complete isolation scheme is adopted. For specific related issues, please refer to this link.

Since we adopt a completely isolated solution, there are only two options when we want to transmit the request and response data for the test request. The two solutions are either when the server is started all the data is specified in the test/config/global-setup.js file or the data is transmitted through the network when the server is running, the path is specified and the network request of the path will carry data and the data request will be specified in the closure of the server. Therefore, both options are supported here. I think it is more appropriate to specify your own data in each unit test file, so here is only one example of specifying the data to be tested in the unit test file. Regarding the data to be tested, a DataMapper type is specified to reduce exceptions caused by type errors. Therefore, two data sets are exemplified here. In addition, regular expressions are supported when matching query and data. The structure of the DataMapper type is relatively standard.

In the below two unit tests, the data to be tested is specified in beforeAll. Note that beforeAll is return setSuitesData(data) because the unit test is executed after the data is set and the response is successful, followed by the normal request and response whether the assertion test is correct.