Using mocked interactions from pact unit tests for stubbing in integration tests

idea.md

An idea: Set up an interaction for a unit test (using strict, exact matching), but specify that it can be used for stubbing in a later test, and specify the route that it should be matched against (with optional tags?). The Mock Server would write these interactions to a separate file, or add metadata to them in the normal pact file. Then, during an integration test, interactions can be loaded and will act as stubs using "type based" matching (something_like).

This means that our stubs will be verified as well as our mocks.

helloProvider
      .given("a thing with ID 1234 exists")
      .uponReceiving("a request to update a thing")
      .withRequest("put", "/things/1234", {name: 'Updated thing'})
      .willRespondWith(200, {
        "Content-Type": "application/json"
      }, {
        name: 'Updated thing'
      }).andSaveAsStub({path: "/things/:id", tags: ['integration']});

Might work?!?!

Sorry its taken me 3 months to get to this. Is there a canonical place where big picture pact stuff is discussed? I struggle to keep track of the interesting discussions we have on where things are going scattered through github.

Here are some random thoughts I have on this:

If this is what the unit test looks like, how do you imagine the integration tests would look? Are you thinking that the integration tests would just say "give me all the interactions tagged with integration"?

How far would you go with the fussy matching? The above example creates a "thing" with the name "Updated thing". Would you want the fussy matching to support passing any name (so the integration tests just care that name is specified but don't care about the value)? Given there is sometimes a relationship between the request body and the response body that might get complicated.

There is also sometimes a relationship between different requests, e.g. you might have a test that wants to do a GET request for /things/1234 in the unit tests. How would you represent this interaction so that the integration stub behaved correctly. You don't want the stub server to respond to a GET on /things/abc if the PUT you did was /things/123.

Stepping back from this, having the integration test stub server match responses in a different way from the unit test mock server brings with it a bit of complexity, so I'm starting to question the assumptions that it should work this way. You seem to be a lot more concerned then I am about having the integration stub mock server care about exact values. I assume you've been burned by something that I haven't. Can you explain in a bit more detail why you think this is important?