Abstract: In this issue, I will briefly discuss the importance of using service contracts in service interaction scenarios and the necessity of contract management. Finally, I will briefly introduce contract testing.

1. Problems caused by service interaction

In the last article, we provided a systematic overview of the testing techniques commonly used in various DevOps processes.

Following the previous figure, we simply draw the invocation relationship of the internal service of a system application: The delivery of a large system may involve the integration of multiple ISVs, each of which has its own front-end, gateway, back-end and other micro-services. In addition, each ISV or service has its own SE, developer and tester, and has its own relatively independent version evolution. There are call relationships between services.

Think about it. What are the problems that arise?

  • Through interface documents or table management interface content, both and multiple parties of service interaction frequently connect interface information of interactive calls, which is frequently updated, cut constantly, and disorderly, making people crash.
  • As a result of service dependence, it is necessary to wait for the completion of the development of the underlying services before joint debugging and docking and integration testing, which is inefficient.
  • If the invoked service interface does not meet the requirements, the interface is missing, or the interface cannot be synchronized, you need to wait for the version synchronized, which causes a waste of resources and time.
  • The service is constantly evolving. The version of the calling service and the called service will change the interface with the increase of external requirements, Bug modification, code reconstruction and other factors. The interface calling service often fails to obtain interface changes in time, resulting in damage to the overall business.

2. Service Contracts — a solution to the service interaction problem

How to solve the complex intermodulation problem among services? In this section we’ll talk about contracts and contract testing.

For the most part, a contract is a letter of credit entered into by two or more parties with mandatory compliance. Consumer Driven Contracts Testing is the full name of contract Testing, which was first seen in 2011. The question of “contract” and “who provides the contract” is clearly described in the name of “Consumer-driven Contract Test”.

Generally speaking, it is the Consumer who tells the service Provider his expectation on input and output data structure, performance and concurrency in the agreed format, and the service Provider signs and agrees, which forms a service contract, and the service Provider develops the service capability by taking and combining all the contracts of the consumers. Form external commitments or schemas for your services.

The model is as follows: Consumer services A, B, and C call service provider SERVICE A, and consumer services A and C service provider service B. The service provider will generate one contract file according to the expectation of the consumer to meet the demand of the consumer.

What are the benefits of contractual interaction between services?

1) There is a “legal basis” for the use of the contract, the docking of both sides of the interface invocation, and the demarcation of the problem, so that the problem will not be confused, unclear, and back and forth.

2) By using contract, the interface form and import and export expectation of both delivery parties are determined. The consumer end and service provider end can develop services in parallel, and conduct pre-integration test by using contract in the development process, without waiting for integration test, which greatly reduces the communication cost of joint commissioning.

3) Because of the existence of the contract, the use of the original interface at the service consumer end can be seen as a whole, so that the change of the interface can be traced, and even the change can ensure the security and accuracy of the change.

4) The consumer side can also know the change of the API of the server side through the change of the contract

3. Problems of contract interaction

In Chapter 2 we look at the basic flow of contracts. 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 what is the problem with this model? Let’s consider the following question:

  • The contract between the two parties is available, but the oral agreement is empty. How can the contract be stored and tamper-proof?
  • Are email interactions and meeting notes difficult to maintain?
  • In sensitive markets, are contracts offered by consumers compliant with normal demands and compliance?
  • In multi-ISV, multi-department collaborative applications, what if consumers frequently refresh contract requirements?
  • How to deal with the normal need to refresh the contract, how can the contract back or backtracking?
  • Driven by the consumer end, will the consumer end have too much power and too much say, forcing the service provider end, and eventually lead to the whole system being neither fish nor fish?

As can be seen from the above questions, since contracts are very important, it becomes more important to design and control contracts.

4. 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 add a new 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 change of contracts, and to merge contracts with multiple consumers.

The contract management link solves problems such as contract storage, access authentication and imtamability, traceability and rollback. This avoids the aforementioned problems and sacrifices some flexibility, but in large systems it is worth it.

Let’s see, the consumer contract generation and download process becomes the following flow:

At the same time, if the service end takes the initiative to change the contract, it should also get the approval of the consumer end and the review committee. After the review and integration, consumers and service providers download the contract from the contract management platform for use. The process becomes as follows:

5. Contract testing

In previous chapters, we spent a lot of time on contract generation and the role and importance of contracts in service interactions, so testing contracts is also important. Let’s talk briefly about how to test contracts.

Contract testing is not component testing; contract testing and core testing are also done through apis. Each consumer is only concerned about whether their expectations are met, so they only need to test against the approved contract document they provide. On the other hand, the service provider needs to satisfy all consumers’ demands and test all consumers’ contracts, and all contracts need to pass the test. As follows:

Because in real development, Consumer and Provider are developed simultaneously after the contract is signed, Consumer and Provider are tested separately. The general contract testing process is as follows:

The test environment for the Consumer service needs to be built with the Mock Provider service using contracts:

In the test environment of the Provider service, test the contract test cases generated in the contract file signed with consumers to verify whether the interface provided by the Provider meets the requirements of consumers and whether the interface is changed. Once the interface changes, the contract test case fails.

As mentioned above, a contract is formed when a Consumer informs the service Provider of its expectations on input and output data structure, performance and concurrency in an agreed format, and the service Provider signs and agrees. The main content of the contract test there is these aspects:

Support for contract testing tools such as Pact, Pacto, Janus, CloudTest, and Swagger can meet some requirements. Pact tools are commonly used in the industry. Here is a brief description of how Pact tools work.

Consumer testing:

The Provider test:

We also added the pros and cons of the Pact tool

6. Sample service contracts under microservices

The contract is usually in the format of a YAML file or JSON file. The CSE micro-service contract is used as an example.

Conclusion: In this issue, I will briefly discuss the importance of using service contracts in service interaction scenarios, the necessity of contract management, and briefly introduce contract testing. There are many guidelines for the use of contract testing tools that are not expanded in this article. Under DevOps, contract testing also needs to be integrated into the pipeline. Welcome to continue our conversation.

This article is from The huawei cloud community “Talk about DevOps testing technology (2) Talk about contracts and contract testing”, the original author: Liu Ge.

Click to follow, the first time to learn about Huawei cloud fresh technology ~