Abstract: In this issue, I will briefly talk about the importance of using service contracts in service interaction scenarios, as well as the necessity of contract management, and finally briefly introduce contract testing.
1. Problems caused by service interaction
In the previous article, we systematically listed the testing techniques commonly used in each process of DevOps.
Following the figure in the previous article, we simply draw the invocation relationship of the internal services of a system application: the delivery of a large system may involve the integration of multiple ISVs, and each ISV has its own front-end, gateway, back-end, etc. Microservices, and each ISV or service has its own SE, development and testing personnel, has its own relatively independent version evolution, and there is a calling relationship between services.
Think about it, what problems does this cause?
- The interface content is managed through interface documents or tables, and the interface information that is frequently connected and called by both sides of the service interaction and multiple parties is frequently refreshed, constantly cut, and messy, which makes people crash.
- Service dependence leads to the need to wait for the underlying services to be developed first before joint debugging and integration testing, which is inefficient;
- At this time, if you find that the called service interface does not meet the requirements, the interface is missing, the interface cannot be debugged, etc., you need to wait for the version to be debugged again, resulting in a waste of resources and time;
- Services are constantly evolving. The version of the calling service and the called service will change due to factors such as external demand increase, bug modification, code refactoring, etc., and the interface calling service is often unable to obtain interface changes in time. result in damage to the overall business.
2. Service contract - a solution to the problem of service interaction
How to solve the complex joint debugging problem between services? In this chapter, let's talk about contracts and contract tests.
Gu Ming suggests that a contract is a credit document signed by two or more parties with mandatory compliance. The full name of contract testing is Consumer Driven Contracts Testing (Consumer Driven Contracts Testing), which was first seen in 2011. The question of "contract", "who provides the contract" is clearly described in the title "Consumer Driven Contract Test".
Generally speaking, the consumer (Consumer) tells the service provider (Provider) in an agreed format about the data structure of input and output, performance and concurrency, and the service provider signs the agreement, which forms a Service contract, the service provider combines the contracts of all consumers to develop service capabilities, and forms an external commitment or schema of its own services.
The model is as follows: consumer-side services A, B, and C call and access service provider service A, and consumer-side service A and C service provider service B. The service provider will generate a contract document according to the expectations of the consumer to meet the demands of the consumer.
What are the benefits of contract interaction between services?
1) There is a "legal basis" for the use contract, the docking of the two parties to the interface call, and the delimitation of the problem. The problem will not be unclear, unclear, and blamed back and forth.
2) Using the contract, the interface form and entry and exit expectations of the delivery parties are determined. The consumer and the service provider can develop services in parallel, and use the contract for pre-integration testing during the development process, without waiting for joint debugging. Integration testing greatly reduces joint debugging and communication costs.
3) Because of the existence of the contract, the original interface usage of the service consumer can be seen as a whole, so that the interface changes can be traced, and even if the changes are changed, the security and accuracy of the changes can be ensured.
4) The consumer can also know the API changes of the server through the change of the contract
现在我也找了很多测试的朋友，做了一个分享技术的交流群，共享了很多我们收集的技术文档和视频教程。
如果你不想再体验自学时找不到资源，没人解答问题，坚持几天便放弃的感受
可以加入我们一起交流。而且还有很多在自动化，性能，安全，测试开发等等方面有一定建树的技术大牛
分享他们的经验，还会分享很多直播讲座和技术沙龙
可以免费学习！划重点！开源的！！！
qq群号：110685036
3. The problem of contract interaction
In the second chapter we saw the basic flow of the contract. In the normal contract testing process, the contract is provided by the consumer, the service provider complies, and the service test is completed according to the contract provided by the consumer. But, think about what kind of problems exist in this model? Let's think about the next question:
- There is a contract between the two parties, but the verbal agreement is empty, how to store the contract, and how to prevent tampering?
- Are email interactions and meeting minutes difficult to maintain?
- In sensitive markets, do the contracts provided by consumers meet normal demands and compliance?
- In an application system with multi-ISV service providers and multi-department collaboration, what should consumers do if they frequently refresh contract requirements?
- How to deal with the normal need to refresh the contract, how can the contract be returned or backdated?
- Driven by the consumer side, will it cause the consumer side to have too much power and discourse power, force the service provider side, and eventually cause the entire system to be nondescript?
From the above questions, we can see that since the contract is very important, it is even more important to design and control the contract.
4. The necessity of contract design and contract management
The problem of interaction is not as simple as imagined. In order to solve the problem of contract design and control, we have added a link of design control and contract management.
The design control link is similar to the parliamentary communication and decision-making body, which is used to mediate and review the rationality, compliance and necessity of changes of contracts, and to merge contracts with multiple consumers.
The contract management link solves problems such as contract storage, access authentication and non-tampering, traceability and rollback. This avoids the problems mentioned above, of course, at the expense of some flexibility, but in large systems, this behavior is worth it.
Let's take a look, the process of generating and downloading the consumer's contract becomes the following process:
At the same time, if the server wants to voluntarily change the contract, it must be approved by the consumer and the review committee. After the review is approved, consumers and service providers download the contract from the contract management platform for use. The flow becomes as follows:
5. Contract test
In the previous chapters, we spent a lot of time introducing the generation of the contract and the role and importance of the contract in the process of service interaction, so the test of the contract is also very important. Let's briefly talk about how to test the contract.
Contract testing is not component testing, and contract testing and the core are also performed through APIs. Each consumer will only pay attention to whether their expectations are met, so they only need to test according to the contract documents they provide and have been approved. On the other hand, the service provider needs to meet the demands of all consumers, and needs to test the contracts of all consumers, and all contracts need to pass the test. As follows:
In actual development, after the contract is signed, Consumer and Provider are developed simultaneously, so Consumer and Provider are also tested separately. The general contract testing process is as follows:
The test environment of the Consumer service needs to use the contract to build the Mock Provider service:
The test environment of the Provider service needs to be tested according to the contract test case generated by the contract file signed with the Consumer. Through the test contract case, it is verified whether the interface provided by itself meets the needs of the consumer and whether there is any change in the interface. Once the interface changes, the contract test case will fail to execute.
As mentioned above, the contract is formed by the consumer (Consumer) telling the service provider (Provider) in an agreed format about the data structure of input and output, performance and concurrency, etc., and the service provider signs and agrees. The main content of the contract test is the following aspects:
Tools that support contract testing include Pact, Pacto, Janus, CloudTest, and Swagger can also meet some requirements. Generally speaking, the industry uses more Pact tools. Let me briefly describe the process of Pact tools. For specific usage of Pact, please refer to the official website:
Consumer test:
Provider test:
We also add the advantages and disadvantages of the Pact tool
6. Example of service contract under microservice
The contract is generally in the format of a yaml file or a json file. We use the contract of CSE microservice as an example to demonstrate:
Conclusion: In this issue, I will briefly talk with you about the importance of using service contracts in service interaction scenarios, the necessity of contract management, and finally a brief introduction to contract testing. There are many guidance documents on the usage of contract testing tools, which are not expanded in this article. Under DevOps , contract testing also needs to be integrated into the pipeline. Welcome to continue the exchange.
↵
The following are supporting learning materials. For friends who do [software testing], it should be the most comprehensive and complete preparation warehouse. This warehouse also accompanied me through the most difficult journey. I hope it can help you too!
Software testing interview applet
The software test question bank maxed out by millions of people! ! ! Who is who knows! ! ! The most comprehensive quiz mini program on the whole network, you can use your mobile phone to do the quizzes, on the subway or on the bus, roll it up!
The following interview question sections are covered:
1. Basic theory of software testing, 2. web, app, interface function testing, 3. network, 4. database, 5. linux
6. web, app, interface automation, 7. performance testing, 8. programming basics, 9. hr interview questions, 10. open test questions, 11. security testing, 12. computer basics
Information acquisition method:
