I also don't get what the testing scope of the provider should be as in my opinion the Pact documentation is giving mixed information regarding that. E.g. https://docs.pact.io/consumer/contract_tests_not_functional_tests says > In short, your Pact scenarios should not dig into the business logic of the Provider but should stick with verifying that Consumer and Provider have a shared understanding of what requests and responses will be. In our example of validation, write scenarios about how the validation fails, not why the validation fails. However, https://docs.pact.io/getting_started/testing-scope#scope-of-a-provider-pact-test says that > Generally speaking, it's easiest to test the entire service and mock out external services such as downstream APIs (which would need their own set of Pact tests). This gives you some of the benefits of an integration test without the high costs of maintenance. and > Invoking just the controller/adapter layer can lead to meaningless verification results, as the response often depends on business logic that gets executed in lower layers. I've implemented both approaches within the Spring Boot application that we are considering moving to Pact. When just testing the Controller Layer (what WebMvc does by default), the tests on the provider were super easy to get going, but didn't test much code (outside of spring internals) at all. When including the business layer I needed to write custom Bean PostProcessor to auto mock the missing Beans. More mocking was required, and the state setup became somewhat dependent on the implementation of the buisness logic.