What should be the scope of a Pact provider test?

My organization started to use Pact for creating/verifying contracts between REST services/micro services written in Java about half a year ago. We have a hard time deciding what the appropriate scope or grasp of a provider test should be and would love some input from the experience of other pact users out there.

Basically the discussion evolves around where to mock/stub in the provider tests. In a service you would have to mock external calls to other services at least but you have the option of mocking closer to the REST resource class as well.

We boiled it down to two options:

1. The first option is that a provider test should be a strict contract test and only exercise the provider service's REST resource class, mocking/stubbing out the service classes/orchestrators etc. used from there. This contract test would be augmented with component tests that would test the parts stubbed/mocked by the provider test.

2. The second option is to use the provider test as a component test that would exercise the entire service component for each request. Only transitive external calls to other components would be mocked/stubbed.

These are thoughts of pro's for each option

Pro's for option 1:

• Tests will be simpler to implement and will get a smaller footprint
  => higher degree of isolation.
• We probably need other component tests anyway to cover use cases typically not covered in the consumer's expectancies (error flows etc). This way we wouldn't mix different kinds of component tests (Pact and other) in one bag, making the test suite easier to understand.

Pro's for option 2:

• Tests are exercising more of the "real" code => less risk for test bugs due to bad mocking/stubbing.

I would be really interested to hear how your provider tests typically look in this regard.