We are working with Ruby on Rails. We implemented Pact until the Gold level. The questions are: • We are using the webmock gem (see Comparisons with other tools) in our unit tests. We chose an existing HTTP client (on the consumer side) to be validated with Pact. We made a copy of that client to point it to the Pact mock service, and we could successfully generate the Pact file and validate the provider. The pro is that we didn't change the existing code, and the con is that we need to maintain two mock definitions: one for Pact and one for webmock. What is the best practice here? Should we replace every HTTP client occurrence? • When we want to generate a Pact file, we need to define the request body/response body/headers, create a spec, and finally to execute the code. That's fine. The thing is that we need to code trivial expectations (according to the documentation) too. I understand the expectation on functional tests. But in these cases, there is no complex logic in the middle. We are testing the Pact tool itself. What is the purpose creating expectations of something we defined a few lines above?

When you say "make a copy of that client", do you just mean "instantiate it with different parameters"? Because that's exactly how it's intended, so it sounds like you're on track.

You can use whatever tools you like together, the maintenance burden is a tradeoff to consider. Pact has done helpers for stripping matchers out of its mocks, in case you want to use those to reduce duplication. I think there's also a stub server (which I haven't used), if you're thinking of replacing wiremock completely.

When you say "should we replace every HTTP client occurrence", I'm a bit confused. If you have an API client that encapsulates all the interactions, you shouldn't need to be replacing anything 🤔

On the "coding trivial expectations" part, if you're just writing things that are exactly represented by the Pact response, you don't need to add any assertions in your unit testing framework. The rest of the answer depends on how much logic you want to test around the edges. For example, on the consumer side, I parse the responses into domain classes, so there's a validation translation that happens, and I usually want to assert that the JSON is correctly converted.