Original link
https://codefresh.io/docker-tutorial/how-to-test-microservice-integration-with-pact/
Challenge: Micro Integration Testing Service
Migration to the micro-service test our system generates new challenges. In theory each micro-services should be isolated and can operate independently. But in practice, a service if no other part is usually useless. On the other hand - pull topology of the entire system for testing and packaging offset modular micro-services expected to bring a service.
The challenge is how to test without problems after integration with other services. We hope the sooner the better. And again we do not want to reproduce complex production environment. Generally this test is an integrated functional testing or test call-end. But the reality is that when our systems become more complex - bring fewer benefits end. A large number of interdependent lead to false positives and long implementation cycle. Makes testing and debugging becomes difficult to manage.
It even has a test pyramid theory (originally referred to by Mike Cohn in his book 'Succeeding with Agile' middle) tells the story in order to optimize your investment, you need less end to end high-level test, write more low-level unit testing.
Please read this article and take a look Codefresh (https://codefresh.io/codefresh-signup/?utm_source=Blog&utm_medium=Post&utm_campaign=pactT), he is the best for CI Docker.
Unit testing well! But of all the benefits it brings - they no role in the integration testing and other services.
How do we ensure that each service team can separate iterations but can ensure the health of the overall system? How do we achieve continuous delivery, small batch production, rapid feedback, but the service does not cause problems in changing it?
One possible answer is that Consumer-Driven Contract (CDC) test. This test strategy is based on evolutionary patterns one kind of service defined years ago. It is now distributed systems become more suitable for the post to become more common.
Consumer-Driven Contracts：
I try to explain briefly. Consumer-Driven Contracts is in fact a contract for services and service relationships. Means that the former do not want the service provider to provide an interface defined above the level of what (colleagues consumer consumer as much as possible adaptation) - Consumers now to lead the dance. Each consumer to define it needs to deliver the desired service provider and need to be checked. This will integrate the transfer of responsibility to the service provider.
It becomes the following processes:
those in the business contracts are usually described as 'the consumers first' or 'Listen to your customers'. Because you want to provide the best service we need to try to make customer expectations and needs. Instead we assume the right thing.
When discussing the evolution of micro-services - especially important in large enterprises that each service has a team of independent development in. Sometimes these groups may in different geographic locations and regions. This affects the real-time communication and make business functions more challenging evolution.
Testing framework contract
Of course, consumer-driven contracts can be managed through communication and collaboration between the investment team. As may be protobuf, thrift or message body messagepack be solved by using a structured series format. But if you want to manage a defined process - the best use of the framework, especially if it is an open source.
This framework has emerged. This is one of the most prominent and active are Pact and Spring Cloud Contract. The latter only for the project to use the JVM. The Pact use Ruby to write but can support many languages, including Java, Go, Python, Javascript. It is very suitable for complex, diverse systems using micro-services.
Today we'll look at how to define between the two services and verify contracts. Customer service is written in Python. The service provider is written with Go. Testing will be conducted in our CI / CD processes - that is, Codefresh pipeline inside.
Pact
So, Pact how does it work? It starts with the consumer.
The development of consumer services write a test. Define and test the integrated provider. This includes the required status provider, the message body and the desired result of the request. Pact to establish and run a party pile provided for testing based on this definition. The output of this test is going to one or more json file, usually something like this:
{
"consumer": {
"name": "billy"
},
"provider": {
"name": "bobby"
},
"interactions": [
{
"description": "My test",
"providerState": "User billy exists",
"request": {
"method": "POST",
"path": "/users/login",
"headers": {
"Content-Type": "application/json",
},
"body": {
"username":"billy",
"password":"issilly"
}
},
"response": {
"status": 200,
}
},
],
"metadata": {
"pactSpecification": {
"version": "2.0.0"
}
}
}This is the contract, this is the pact. Now they are passed to the service provider. It can also be submitted to the shared git repository, or uploaded to the shared file storage by Pact Broker application.
Once the updated contract - providers need to test it to verify that still meet the requirements. It runs its own verification test rather than the real version of the service by using file sharing pact. If all the interaction is in line with expectations and passed the test - we can go on. If you do not - provide the developer needs to inform the development of the consumer. They can then analyze together what led to the failure of the contract.
This article from the micro-channel public number "malt bread, id" darkjune_think "
reprint please specify. Sweep the micro-channel public concern number.
AC Email: [email protected]
