Hey team, may I ask did anyone use Pact.io in Provider-driven way, means Provider generate contract, then consumer always verify, does this approach make sense? or maybe overengineering comparing with schema validation? Thanks in advance

Kinda. Pact doesn’t support this directly. In Pact, a consumer is a synonym for client (which is not strictly true - it provides http requests, and consumes http responses). Some of the assumptions change if you were able to write a Pact test for a provider - for example, it’s not breaking if a consumer never calls an endpoint that is available.

Thanks a lot for swift and detailed reply!

There are some bullet points here on why it’s not the same as schema tests: https://case.contract-testing.io/docs/Alternatives/contract-testing-vs-schema

in some cases of SDLC, we maybe have API-First driven approach, it means producers manage the schema creation, and build up the "contract"

we maybe have API-First driven approach,

This is very common. I also think it’s an industry wide anti-pattern (for the same reason - do you have a shop where the shopkeeper decides what the customers want? No, it would be better to ask the customers first, then buy those things)

I realise most teams wouldn’t want to do that)

That's correct, in a big scale projects, the challenge is not technical, but the communication between consumers and providers. In terms of

ContractCase

, will it support Provider-driven contract test? if yes, may I ask what's the difference between Schema validation(imagine we ensure all API changes detect break schema changes) and

ContractCase

It already does

in terms of GRPC https://buf.build/docs/about/, the tool potentially can verify and block the break schema changes.

Forwards and backwards compatibility is not enforced: While forwards and backwards compatibility is a promise of Protobuf, actually maintaining backwards-compatible Protobuf APIs isn't widely practiced, and is hard to enforce.

Consider:

message UserTypeResponse {
  string userType = 1;
}

If a provider is updated to emit

"User"

,

"Admin"

and

"Moderator"

, but the consumer expects

"User"

and

"Admin"

that is a breaking communication change, but not a breaking protobuf change. Any automated tooling aimed at detecting breaking changes in protobuf will not see this

imagine above case, consume only can handle

user

,

admin

, but not

moderator

, in this case, we maybe just miss a unit test/integration test to cover

else

status to check if there is a unknown type. but however if producer decided only to emit

admin

and

moderator

, but remove

user

, schema validation is passed, and it won't impact the consumer's functionality, but maybe a feature is gone completely. in this case, more or less, Contract test seems is protecting the "data" between the consumer and producer.

In that example, yes. I would say that generally it is testing the communication between them.

Thanks a lot @Timothy Jones!

One way I have thought making this flow work, would be for a provider to generate and ship the pact tests (or perhaps even just a pact file) with the SDK or client. The client would then need to produce a pact file that is equivalent or a subset of the given pact (assuming it’s not necessarily easy to re-use the tests themselves). If this were true, you’d have better confidence there are no compatibility issues.

I think a workflow like that might help bootstrap new consumers. It's a lot like the "test consumer" pattern I have historically used to TDD from the API side, so a PoC could be made before the consumer started in earnest.

Yeah. With tools to chop and change contract files that would be really easy. Of course, those tools don’t exist yet (at least for any framework that I know)

The hard part is being able to compare two pact files that have the same structure, but different matchers - as the semantics on those comparisons get difficult. But you could imagine starting with a simpler version where that is disallowed, and then basic utilities to splice and dice a pact file would be chefkiss