GM team, I’m wondering about the process with contract testing... person in charge of the contract tests(dev/qa) should mock the provider and consumer, is that right? or should that person use the actual API code to make sure we are hitting the endpoints with the correct parameters? Currently what I’m doing is creating the provider/consumer tests and I’m defining the methods with the post/get adding the headers, etc.... but I’m not using the app code, I know what the endpoints are and I’m using Postman to get more information about headers, response, etc. This is the piece that’s not clear to me, should we mockup everything (provider/consumer)? or basically we should use the real API calls from the code? What happens if the devs change something in the actual API code and they don’t tell me, my tests will continue passing because they are not hitting the updated code. Does that make sense?

That’s not exactly how contract testing works. Assuming you’re referring to consumer-driven contract testing, you don’t mock anything, that’s taken care of by Pact. You write consumer tests that: • define expectations about provider behaviour and write those to a contract • test consumer implementation using a mock generated from the contract by Pact (you get this for free) Contract is then distributed to the provider (through a broker such as PactFlow) and the provider uses that contract to verify that its actual behaviour meets expectations written in the contract. To do so, Pact generates a mock consumer, again, automatically. This image says it all really:

Thanks @Bas Dijkstra, in that case the provider is the Real API(When I said real api I mean the code devs are using)

Yes, indeed.

interesting, one more question…. based on this example https://github.com/pact-foundation/pact-js/tree/master/examples/e2e what should be the real api? I know it’s just an example but I took that as my base and I’m replacing some URLs to match my API, but as I said before doing that I’m mocking up the API calls.

Usually, in dev, I'd start my local dev API up (in a testing mode so Pact can tell me what states to set up), and run contract verification. In CI, it's the same, just not on my local computer. That's the older way, where you expose a state-change endpoint. There are a few different options, though, depending on what the provider is written in.

GM team, I’m wondering about the process with contract testing... person in charge of the contract tests(dev/qa) should mock the provider and consumer, is that right? or should that person use the actual API code to make sure we are hitting the endpoints with the correct parameters?

The way to think about Pact tests is to treat them as if they were a unit test. Once you have that frame of mind, how you test becomes a lot more obvious.

Currently what I’m doing is creating the provider/consumer tests and I’m defining the methods with the post/get adding the headers, etc.... but I’m not using the app code, I know what the endpoints are and I’m using Postman to get more information about headers, response, etc. This is the piece that’s not clear to me, should we mockup everything (provider/consumer)? or basically we should use the real API calls from the code?

You only mock the boundaries, but obviously you want to be testing the behaviour of the code under test. On the consumer side, this is the API client. Usually you wouldn’t have to mock too much here, except of course the API provider (and Pact will provide that mock). On the provider side, this is usually the whole API and you would mock downstream / 3rd party systems

What happens if the devs change something in the actual API code and they don’t tell me, my tests will continue passing because they are not hitting the updated code. Does that make sense?

Yes, it makes sense, but you shouldn’t be doing it this way if you go back to the “it’s a unit test”. Really, these tests should live alongside the code and would change with the code. If your contract tests continue to pass when the implementation changes, you’ve done it wrong. Contract tests aren’t regression tests or acceptance tests to prevent behaviour changes - they can and should change. Pact and the broker will ensure the various components remain compatible

Thanks @Matt (pactflow.io / pact-js / pact-go) for the detailed answers. I think this was very productive…

No conceptual difference 🙂 It depends what interfaces you have between consumer and provider, and lifecycle management might be different than long-running processes.