Hello! I've got a general question regarding provider verification step. What happens when you run it? Is a test request gets generated from the pulled pact and goes through the providers handlers? We have argues in the team regarding whether it is the same when you run provider verification tests and when you generate provider's spec, push it to pactflow and let it to compare the consumer's and provider's pacts.

Sounds like there might be some confusion between consumer-driven and bi-directional?

right...some people of my team think it is more easy to just generate a pact for provider and let broker to compare pacts. But I am not quite sure this will be the same as if we run provider verification. So this is what I am asking - if during provider verification we do more than just pulled consumer pact and provider specification comparison

Yes, there's a significant difference. The consumer-driven flow gives more reasoning power. There's a nice article about it here: https://www.google.com/amp/s/pactflow.io/blog/schemas-are-not-contracts/amp/

thank you! will read this!

Np, I hope you can win your people over 🙏

me too :)))

it is more easy to just generate a pact for provider and let broker to compare pacts.

Definitely not.

right

When a pact file is written, you are guaranteeing that you can send that request, and promising that you will understand that response (for each req/resp pair in the pact)

and how exactly verification on provider side is made? is a request generated from the pact and "send" through the provider's handler?

Yes, that’s right. You can think of it as replaying the requests, and seeing if the responses match what the consumer will understand (that’s not quite what happens, but the subtleties don’t actually matter in practice).

got this!

You’re welcome! Let us know if there’s anything else we can help with.

I will! thanks!

Hi Team! thank you so much for your detailed explanation! happy to be talking to someone who actually make this work. So am i right that you’re saying that BCDC should only be used as a compromise when let’s say the “provider team” doesn’t want to put too much effort? 😉 Thanks for sharing the post - however i was under the impression that the idea of it is to prompt people to use the commercial pactflow solution which is supposed to help with most of listed concerns (which we already do!) - in conclusion it suggests to learn how you can make schemas work with contract testing Speaking of the specifics: my original idea was to implement it in a way described in pactflow tutorial or workshop (provider schema created -> provider schema validated against the provider implementation in a “blackbox” style -> validation results and schema uploaded to broker -> broker validates consumer pact against provider schema). With such an approach it doesn’t seem to me that the concerns listed in the post are real, lemme try to go through them: 1 - not sure we faced any issues with that; if we use .yml schema the broker seems to understand it in a way we want. or am i misunderstanding what that means? 2 - totally valid! but is this fully solved with CDCT? for instance could we test with 5xx error from provider when it’s not caused by the inputs from consumer? 3 - looks like supposed to be solved by “provider vefification step” from the workshop 4 - same (“provider vefification step” ) 5 - same (“provider vefification step” ) 7 and 8 apparently are supposed to handled by pactflow 9 - not sure is this could be a problem with OAS yaml schema ? In general, i understand what you mean when you say that the interactions generated by consumer and “replayed” against prodiver are more “real”, i have same “feeling”; but the tradeoff seems to be fair considering much easier implementation especially with multiple consumers Is there something i am missing? would really appreciate any pointers 😉 thank you guys and have a great day!

Bi-directional is also a helpful stepping stone when adding testing to a large, established ecosystem. If you're starting from scratch, there's pretty much no compelling reason to avoid consumer-driven 😇

I’m a bit unclear on what points you’re replying to with the numbers

ok seems everyone here is leaning to consumer driven approach then we shall try it, thanks again guys for your help! @Timothy Jones oh sorry i was replying to the problems listed and numbered in the post Boris shared above in the thread 😅