Hey everyone! 👋 I'm hoping to get some community feedback on my company's approach to contract testing, as it feels quite different from my previous experience. I want to make sure we're on the right track. Here's a quick rundown of our current setup: • Consumer Side: When consumers generate contracts, there isn't a verification step against a mock service. The consumer code doesn't seem to be asserting its expectations before the pact file is created. • Provider Side: For verification, we send the requests from the pact file directly to a live, deployed environment called "temp". This is a task-based environment that contains recent feature changes. We are not using mock servers or any test doubles; it's a real, running env with services. • Centralized Repo: All contract tests for all our services are being written in a single, centralized repository. My main concern is the dependency on a live environment for provider verification. This feels less like a contract test and more like a targeted integration test. The core benefit of testing components in isolation seems to be lost. So, my question for you all is: Is this a valid implementation of contract testing? I'm worried that by relying on a live environment, we're missing out on the speed, reliability, and independent deployability that contract testing promises. It feels like we're just asserting a response from a live server, which doesn't seem to be the point. Any thoughts, advice, or validation on this would be hugely appreciated! Thanks in advance.

ideally pacts are stored in pact broker because that stores the contracts/verifications and can co ordinate when new verifications need to be run. running against a live environment isn't ideal. You more than likely need control of test data for each test for setting up provider state, and if the environment isn't spun up freshly for each run, you get the issue that others might use your environment and change your system under test which is less than ideal. it's recommended to run your provider verification pre deployment, and have verifications associated with the version of code that did verify it. if you use a pact broker, and webhooks, when you publish a new contract requiring verification, will trigger webhooks for each deployed/released version of the provider and its latest version of its main branch. You ideally need to test again each of these specific versions to be able to run can-i-deploy effectively into all of your environments

No they are calling verify function as empty, it means without asserting anything they are creating contracts.

Pact should still check the client has issued the expected calls, even if you don't make any unit test based assertions on your sut's result

yes they are doing that, but they are not asserting any unit test from consumer codes using verify function. On the other hand they are not using pact broker, using some store for keeping contract jsons then after creating temp env for task based, they are running in the pipeline like automation tests.

I would wholly recommend advocating for some best practises in a few areas to improve your contract testing experience with Pact. I would suggest your team is around here https://docs.pact.io/pact_nirvana/step_3 you can improve the quality of the tests and verification over time. moving to verifications against a service spun up specifically in CI and then integrating with a pact broker would be my next move

aggree

adding in some unit test assertions is a great cheap net benefit from the existing consumer tests as it can replace other tests that overlap if there are any. it also allows you to trim response expectations until your system under test no longer operates ensuring your tests only capture requirements on your provider, that your consumer actually relies on, granular down to the field level

Yes, I can understand the situation on the consumer side, but the real issue here is the provider side. Because there, the pact server is sending the request directly to a real server, which means there is no state handler or anything like that. They are sending the real server, and they are asserting the response with the contract. I think this is not contract testing

Well, the contract test is, er, simply validating that the service conforms to the generated contract. So you can test against a deployed environment. But as you note and @Yousaf Nabi (pactflow.io), not ideal. I think it is still contract testing. But it does blur the line between contract testing and more heavyweight integration testing. One of the goals of Contract testing is to be "fast", a quick API validation between two parties. We write our Provider test in the same repo as our service, so I can just use existing tools to stand up a local instance of the service, stub out whatever dependencies might exist, and get a stable Provider test.

No they are calling verify function as empty, it means without asserting anything they are creating contracts.

I’m still a little confused. Could you perhaps show us what you mean by pasting a snippet of code or pseudo-code ?