Generally speaking, development engineers have defined microservice interfaces in the early stage of development, and test engineers and development engineers start their own development tasks almost simultaneously. However, this harmonious work scenario is soon destroyed by the spider web-like microservice call relationship, and almost all projects will have interdependencies, such as service A depends on service B, service B depends on service C, as shown in the following figure:
This confusion is mainly reflected in: when the continuous integration pipeline deploys service A, because the corresponding development engineer team is also doing synchronous transformation, service B in the test environment is unavailable;
Because Service B depends on Service C, and Service C has not yet been developed, even though Service A and Service B are fine, there is no way to complete the interface testing of Service A.
With the development of microservices becoming more and more complex, the call relationship between services is as disordered as a spider web, making it difficult for you to figure out how many layers of external dependencies there are, and how many external interfaces an interface depends on. This has led to the tragic ending that although the system under test has been developed and the test script is ready, the test work cannot be carried out.
Mock Framework Choice: What to use to implement the stand-in for Service B
For the chaotic call relationship, my idea is: my service under test is service A, then I don’t care if service B is good to use, I just need to ensure that service A can complete the process, I can complete the interface test task. Following this idea, each mock service is actually a simple service B, the difference is that it does not need to implement the processing logic of the original service B load, as long as it can give the corresponding return according to the processing logic of service B. Therefore, some teams also refer to such a service as a baffle system.
Mock service design experience
After choosing the mock framework, you can do the decoupling of the various external dependent services, but I would like to tell you some of my design experience about mock services.
First of all, simplicity is the first element. No matter how complex the business process handled by the original service B, when you design the mock service of service B, as long as you care about what kind of parameters the corresponding service will return when service B can handle several types of parameter combinations. In this way, you can quickly grasp the design core of Mock Service B, and you can quickly complete the development of Mock Service B.
Second, processing speed is more important than a perfect mock service. If a mock service can return parameters correctly and quickly according to the original service, you don’t need to waste a lot of time on invoking the mock service, it is just a means to assist you to complete the interface test.
Finally, your mock service needs to be lightweight and easy to destroy. Always keep in mind that the mock service is only a secondary service, so no team wants to wait 5 minutes to start a mock service, or 100M of memory. It needs to be quick to start, easy to modify, and easy to migrate.