Hi, we're evaluating Pact (and Pactflow) to see if it can fit into our org's workflow. One thing that might hinder adoption is the need to write the consumer tests using Pact tooling/DSL. I was going through the workshop https://docs.pactflow.io/docs/bi-directional-contract-testing/consumer/#writing-consumer-contracts and it looks like as long as the pact json is properly generated/serialized and pushed to the broker, it doesn't really matter how that file is created (but it's mostly created from mock files). Is this a fair statement? I'm part of a platform team and don't have much context into service's unit/functional tests, so it's been a little hard to wrap my mind around how we'll go from just unit/functional tests to a generated Pact json. Thank you!

the framework is in charge of exactly that: you configure your mock + write a unit test -> the json is generated

As Ulises said, if you use Pact (e.g. a client language framework like Pact JS), it is used in unit tests and the contract file is generated automatically. The idea of the BDCT flow you linked above, is that you can bring your own mocks, so long as you can convert those mocks to a pact format. That would enable you to use mocks you’re comfortable with, but you would need to create a serialiser. For example, customers that use MSW may use https://github.com/pactflow/pact-msw-adapter to do that.

Thank you, I must've missed the answer. The idea would be to not have to use the client language framework, and just be able to generate the pact file (but use the cli tools to push it to the broker). The services are in JS, and I'm still working my head around what those services use for mocking data, or even if stubs are used instead. I think we want to avoid having to subject those teams to having to write/maintain new tests in addition to the unit/integration tests they already have, so if there was a way to say to teams "use your existing data/process, our team will provide the tooling to get that data into a pact format and handle pushing it to the broker" then I think it'll go a long way in adoption.

I can fully understand the sentiment, we have considered this ourselves and sort of went the other direction: these are “different” tests, and so they should be written accordingly. Let me give you an example, we have apps which use a client to talk to a service. This service has 2 API versions, V1 and V2. This app has a thin wrapper around the client to make the app code nicer to read, maintain, all of the good stuff that encapsulation brings. At the unit/stub/mock/semi-integ testing this thin wrapper is a mock. At the CT level this thin wrapper actually makes requests to the pact mock server. These two kinds of tests serve two very different kinds of purposes. And so they exist (both kinds) and are maintained.

Great answer!

Sorry for the delay in response, but good points to consider. Thank you!