Hi, I need some clarification on consumer-driven testing. On the consumer side, we’re essentially mocking all the requests, correct? This is what generates the contract with that information. However, I’m struggling to understand the provider side. Is Pact Verification done against the actual API, or should we mock the API endpoints to ensure they fulfill the contract requirements? Alternatively, should we be using the real service code for the provider? I tried this, but I was encountering 500 errors when running the provider tests.

On the consumer side, you’re (or, well Pact is) mocking the responses in line with the expectations you define about provider behaviour. On the provider side, you should verify the contract against the real provider. Otherwise, what are you testing? You can mock some downstream dependencies (databases, 3rd party services) but the responses should be produced by an actual, running provider. I’ll try and have a look at those 500 issues for you, I think you posted them in the #C9UTHV2AD channel? It might take me a couple of days though.

Thanks, that’s what I thought about the provider, it doesn’t make sense to me to mock the service again 🤔

What about validating async messages (RabbitMQ, Kafka, etc.)? The provider generates these messages in these cases, so it feels more like a unit test than an integration test with the application running. Does that make sense?

Yes that is correct Marcus, Pact stands in for your message queue, so you only need to test the portion of your code which will generate the message. If you are able to suitably design your application such that the application logic is split from the transport logic, the scope of the test is far smaller than that of traditional pact http testing scope on the provider side