1. Teams can work in parallel
With Mock, front-end and back-end personnel only need to define the interface documents to start working in parallel, without affecting each other, and only in the final joint debugging stage. Solution; if the dependent interface is not ready during the testing process, Mock can also be used; there will be no situation where one team waits for another team. In this way, the development self-test phase can be carried out as early as possible, so that the timing of finding defects is also earlier, which is beneficial to the guarantee of the quality and progress of the whole product.
Unit testing is the cornerstone of TDD implementation, and TDD often encounters situations where co-modules have not yet been developed, but with mocks, none of this is a problem. After the interface is defined, the tester can create a mock, add the interface to the automated test environment, and create tests in advance.
For example, if you need to call a resource outside the "wall" to facilitate debugging yourself, you can mock one yourself.
If we need to call a post request, in order to obtain a certain response, to see whether the current system can correctly process the returned "response", but this post request will cause data pollution in the database, then we can make full use of Mock to construct a virtual The post request, we can specify the return for him.
If we need to create a demo program and do a simple UI, then we can do a demo without developing a backend service at all. Speaking of demonstration, if you have already built a system and need to demonstrate it to customers, but there is some real data in it that you don't want users to see, then you can also use the Mock interface to replace all these sensitive information interfaces.
If there is an interface with 100 different types of returns, we need to test whether the system can respond normally under different returns, but some returns basically do not occur under normal circumstances, do you have to do everything possible to do various things for the system Hands and feet for him to return for testing? For example, we need to test whether the app crashes when the interface has a 500 error, don't tell me you must do something to the server code to make it return 500. . . With mock, all this is easy to do. You can simulate what you want to return, and mom no longer has to worry about my test coverage!