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
contexwhich has nothing to do with thecontexof 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.
