Hi guys, I am beginner in contract testing, and checking the feasibility of using this for my team. I found many great examples about verification between 1-1 consumer and provider case in internet. But in real world, there are many situations about M consumers to N providers. And I have 2 questions: 1. when I verify a provider which have 3 sub-providers. Do I need those contracts of sub-providers is verified and up-to date first?

For purposes of contract verification, not necessarily. But the use of

can-i-deploy

will tease out the relationships. If any of them have somehow gotten out of sync,

can-i-deploy

will detect it and explain to you which versions of the ecosystem are incompatible, and prevent you releasing a breaking change

Thanks @Matt，but still not sure if I understand correctly: For contract verification, I need to run the provider with all contract requests from customer side as input. And we can mock the sub-providers for the execution. To make sure all mock servers running correctly, we need to ensure all contracts in the sub providers’ side are correct and up-to-dated first, right?

And we can mock the sub-providers for the execution. To make sure all mock servers running correctly, we need to ensure all contracts in the sub providers’ side are correct and up-to-dated first, right?

I wouldn’t recommend using the Pact mock servers for more than one layer of testing at a time. That is, during Pact provider verification you shouldn’t use Pact mock servers for downstream providers, you should just stub them using whatever makes sense for your framework/tech

btw, separate to the question, this diagram looks like it expects all contracts for provider Y to change in sync with the provider version (v2), but those versions can move faster or slower than a major version. (i.e. there can be a contract change every commit, or there could be no contract changes in a commit)

I think maybe I missed one point. In most of the situations when verification is failed in provider, we don't alter the contract being verified, right? We may fix the code in the provider until it can fulfill all the expectations of the contract, but we will not alter the contract. For consumer driven contract, the only situation we will create a new contract is when we replace the consumer with a new version, and we need to generate a new contract and verify it.

That really depends on what's wrong. If the consumer was requesting or expecting something incorrect, it will have to change. Basically, both sides can change at any time, and the automated-integration-triggering workflow should highlight breakages (or confirm compatibility) in the minimum time possible. Then,

can-i-deploy

will tell you what's safe to deploy (right now, or together in the future)