Not if you're using the traditional approach Sorry, misunderstood the question. You're asking about bi-directional contracts, right?

I'm not sure what I'm asking about, I'm new to pact 🤓

Bi-directional contracts would be where the provider uploads an OAS spec as it's side of the contract

How does the consumer verify the providers contract? What if it doesn't use all endpoints of the provider?

By creating its own version of the contract based on what it uses and then the broker verifies do these match

I've had a bit of a read up on BDCT - Let's say the consumer only has a single test for

GET /foo

and in that test, the provider is assumed to respond with a

200

with the body 'x'. The consumer uploads the contract based on that single scenario. The provider uploads it's OAS which says that

GET /foo

can respond in two ways: • With

200

and body 'x' • With

400

and body 'y' Will the the contract compatibilty check (run by PactFlow) alert us in this case? What if the response bodies are compatible but only the status codes differ? As the development team maintaining the consumer, in this scenario we want to be told "Hey! You need to handle the case where the provider gives you a 400 back as well!". NB: This illustrates (what in my eyes is) a major shortcoming of the regular (CDCT) contract testing: • As the team developing the consumer, you need to remember to look at the OAS for the provider and make sure you exhaustively handle the status codes + respond body shapes it could return • If the provider is updated to return new status codes / response bodies, that is a breaking change for the consumer. Yet the consumer will have no way of knowing about it & the team developing the provider won't know that they are potentially breaking things for their consumers! ⚠️ @Brendan Donegan what are your thoughts on this?

My 2 cents on this - it's really up the consumer to tell the provider what it cares about, regardless of CDCT or BDCT being used. So if the consumer has code that cares about a 400 being returned then it should have a test for that scenario

Thanks Brendan. I'm not sure I agree however - while I get that contract testing isn't a replacement for out-of-band communications between implementing teams, assuming the possible 400 response is something the provider team have recently added to their API, the consumer team "don't know what they don't know" - they don't know there is a 400 status code that they should be interested in. What I'm getting at here is this is a case where we're reliant on that out of band communication happening.

Unless you have a specific business case to do some based on that 400 class of error, on the client side, why would they care?

Unless you have a specific business case to do some based on that 400 class of error

Well that's one good reason, but another reason is that if there's a new shape of 400 response, there's a possibility that you were previously making requests that could be now invalid.