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.