Hi 👋 , we are thinking of adding Pact to our tests. We have one concern about running the provider's verification. Currently, we are running our services locally in isolation by binding the application interfaces to mocks using IoC. Now, if we want to start using Pact we will have two mock systems, one for tests, and one for an isolated local run. I want to be able to configure and run the Pact mock server locally when running the application. --or-- Use the existing mocked implementations to configure the expected interactions in the tests. Is that possible? Do you have any idea on how to do that correctly? I opened a discussion in GitHub with more details: https://github.com/pact-foundation/pact-js/discussions/887 What do you think about this concern? How do you run your app locally in isolation?

There's a lot to unpack here. The example looks like a consumer-side scenario, but your explanation talks about provider verification 🤔

I don't think I understand your question, sorry.

I had to look at the sample code to work out the inversion of control specifics, it's just a DI framework binding.

Oh right. I think I understand the question - you're saying that you have a pact verification for your service's endpoints, and your service makes some downstream service calls, which you would usually mock during testing. But, if you also test those downstream service calls with pact, then you're thinking "maybe we can just reuse what we set up for pact instead of manually maintaining mocks"?

Thanks @Timothy Jones! That was really insightful, few thoughts... Seems like I better understand now the benefits of adding Pact, it can validate that my mock classes mimics the provider correctly. Which improves the confidence on my unit tests, it also gives us coverage on the live concrete implementation. As you said in the slide, there is some overlap between functional tests and contract tests, which is good because it validates that isolated run and production run works the same. Just need to find the balance. This is stronger than traditional integration tests where your mocks and live implementations are separated. To maintain this overlap correctly, I need that one of these will happen: 1) Mocks will use Pact 2) Pact will use mocks 3) Pact and mocks will use another component that maintains mocked data. I feel like option 2 suites us best. If we will also implement a state handler, we need it to dynamically mutate our mocks from outside. Our mocked classes already has this possibility and it really fits our needs.

Option 2 might be easiest at first, but you may have a bad time long term. The reason for this is that to get the best use from pact, you'll want to use matchers

Hmmm interesting, haven't thought about the matchers, but if I pass

like(mock.getOrder)

it will have similar result? It doesnt give us flexibility of using the matcher

You should definitely think about flexible matchers 🙂 they're what gets Pact to the sweet spot of "flexible like schemas" but with "the reasoning power of unit tests".

The primary downside of

like(wholePayload)

is that you will only match on the json types of everything. If your payloads are simple then you can totally get away with it. However, it won't work for all payloads, so you might miss things: Cases where this won't work include: • where the client only understands specific values where you need an enum (say

userType

which could be

"admin"

or

"member"

- this is an important part of the contract, because you want to be sure that the backend doesn't return

"someOtherType"

or maybe "ADMIN" if your client is case sensitive) . • If you have any arrays, it will tie the backend to providing exactly that structure • Same thing you have any objects used as maps

Thanks! So I can take the mock result

mock.getOrder(id)

and translate it to a Pact response body more precisely according to the test, something like this:

const order = mock.getOrder(id);
const expectedResponseBody: Order = {
    id,
    name: like(order.name),
    // ...
}

So my pact tests can use my mocks, with the flexibility of using matchers. Right now, this seems the easiest way to manage the mocks in our services. WDYT?

Yes, exactly.

Thank you! @Timothy Jones