Mocking network requests even easier
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
Axios to initiate network requests. This is my 39th Medium article.
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 install
Some commands are specified in the
package.json, which are as follows:
npm run build: The packaging command of
npm run test:demo1: Simply
mockthe network request library encapsulated.
npm run test:demo2: Complete the
npm run test:demo3: Use the library in
Jestto complete the implementation of
npm run test:demo4-5: Start a
proxythe network request through the proxy of
axios, and forward it to the started
nodeserver. By setting the corresponding unit test request and response data, the corresponding relationship is used to realize the test, which is
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.
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.
Jest uses the browser environment simulated by
JSDOM, the startup file
test/config/setup.js is configured in the
setupFiles attribute configured in
JSDOM is initialized here.
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
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
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 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
demo3 can be tried to run through
npm run test:demo3. The example in
demo2 is actually complicated to write. In
Mock Functionshas the implementation of
mockImplementation which can be used directly.
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
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
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 the
test/config folder then we need to add two more files in there which are
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
contexwhich has nothing to do with the
contexof 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
Now, there may be suggestion that why the server should not be started and shut down in the
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. When
afterAll 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
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.