Contract testing: Addresses microservice testing

FROM https://blog.csdn.net/crisschan/article/details/88310201

Why contract tests

Contract Testing first saw me in an article by Martin Fowler. (the original here interested can go to take a look at https://martinfowler.com/bliki/ContractTest.html)

In this article, first of all, says the TestDouble disadvantage, including TestDouble (interested in this definition can see https://martinfowler.com/bliki/TestDouble.html)

In fact, we rarely talk about it. To explain contract testing, we’ll replace TestDouble with MOCK in this article, which may not be correct either, but it’s a quick fix.

MOCK services are known to exist primarily to help resolve external dependencies. The two teams are responsible for the development of Service1 and Service2 respectively, where Service1 calls Service2. During the testing process, it was easy to test Service1 due to network speed and service instability between Service1 and Service2, so many of us first thought that Service2 could be replaced by a MOCK service. This is an effective method.

However, the development cycle, iteration cycle and iteration frequency are getting shorter and faster. If Service1 uses the MOCK service of Service2 during development or testing and Service2 is upgraded by its Own team, but the MOCK service invoked by Service1 is not upgraded, This leads to the inconsistencies that can only be found during integration testing, which will greatly affect the progress of the project or iteration cycle.

In an era of microservices where service interfaces (providers) are invoked by services (comsumers), the producer-consumer model gives rise to contract testing (better known as consumer-driven contract testing, CDC). CDC defines tests from a consumer perspective, in the form of contracts for API providers to implement functionality. Current mainstream CDC testing frameworks include PACT (https://github.com/pact-foundation/pact-specification)

The CDC core principles (from: https://www.cnblogs.com/jinjiangongzuoshi/p/7815243.html) :

CDC is an interface contract proposed by the consumer, which is delivered to the service provider for implementation, and the contract is constrained by test cases. Therefore, the service provider can change the interface or architecture implementation without affecting the consumers if the test cases are satisfied.

CDC is a test of an interface to an external service that verifies that the service meets the contract that consumers expect. Its essence is to maximize the satisfaction of the business value realization of the demand side from the goal and motivation of stakeholders.

Pact’s contract testing process

As shown in the figure above, after using Pact to complete the contract test, we first test the Consumer against the original test case, replacing the Provider with Pact when the Consumer needs to interact with the Provider. During testing, Pact logs all of the Provider invocation requests (stored in a Json file), which is the consumer’s contract. When testing a Provider, you do not need to complete a new test case for the Provider. You only need to interact with the Provider using the consumer contract recorded by Pact as input to the test to verify that the Provider satisfies the consumer contract.

This also shows that contract testing is neither a unit test nor an integration test, but a layer of testing behavior between unit tests and integration tests.

Here are a few scenarios from Pact:

(from: https://insights.thoughtworks.cn/about-contract-test/)

Applicable scenarios:

The team can control both the Consumer and Provider sides of the development process. It is suitable for the Consumer driven development scenario. For each individual Consumer side, the Provider side can manage the requirements.

Not applicable scenarios:

The functional tests on the Provider side (Pact only tests content and request format) have the same output for different inputs. The current test input needs to rely on the results returned by previous tests

reference

https://www.cnblogs.com/jinjiangongzuoshi/p/7815243.htmlhttp://aleung.github.io/blog/2017/06/21/pact/https://insights.th oughtworks.cn/about-contract-test/

Pay attention to my, FROM:https://blog.csdn.net/crisschan attention test