Physical Address
304 North Cardinal St.
Dorchester Center, MA 02124
Physical Address
304 North Cardinal St.
Dorchester Center, MA 02124
[ad_1]
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.
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.
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
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 Functions
in Jest
.
demo3
can be tried to run through npm run test:demo3
. The example in demo2
is actually complicated to write. In Jest
, Mock Functions
has the implementation of mockImplementation
which can be used directly.
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 thecontex
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.
[ad_2]