Hello everyone, 👋, I’ve been asked to create a working POC for contract testing using Pact in my organization, and I’d really appreciate guidance from the community on best practices for our scenario. Current System Landscape • 7 Micro Frontends (independent repos & deployments) • 10 Microservice Providers (independent repos & deployments) • Almost every frontend consumes most of the backend services • Teams are fully decoupled (separate CI/CD pipelines) Current Pact Setup (POC) • A separate QA-owned repository for contract testing • Consumer tests: -Pact consumer tests written in the QA repo -Requests are constructed manually (HTTP calls) -Verified only against the Pact mock server -No real frontend component or business logic involved • Provider tests: • Provider verification tests also live in the QA repo • Verified using: -In-memory DB -Fake/local server • Not verified against the actual deployed provider base URL This setup is technically working, but: • Contracts are not validated against real consumer logic • Providers are not verified using real provider runtime behavior • QA owns everything, but confidence feels limited • Core Concern > The contracts are being validated in isolation, not against the actual consumer and provider implementations. My Questions- 1. Is it possible (or recommended) to verify Pact contracts against real consumer and provider logic while keeping ownership with the QA team? 2. Are there any established patterns where: • Consumers remain untouched • Providers remain untouched • QA still owns contract definition and verification 3. Would approaches like: • Running provider verification against a real provider instance in a special “contract-test” mode • Using ephemeral environments / in-memory databases • Executing consumer tests through real frontend service layers be considered valid and scalable? 4. From a Pact philosophy perspective: • Is a QA-owned contract testing model like this anti-pattern, or • Is it acceptable as long as contracts are published and verified correctly? 5. In real-world micro-frontend + microservice ecosystems: • Who usually owns Pact tests? • How is trust maintained between teams?

there is a lot to unroll there. let me see if i can do this one piece at a time:

Current System Landscape

• 7 Micro Frontends (independent repos & deployments)

• 10 Microservice Providers (independent repos & deployments)

• Almost every frontend consumes most of the backend services

• Teams are fully decoupled (separate CI/CD pipelines)

that is a lot, but the only thing you should care about is the provider side service and the consumer proxies. You get the consumer contracts from the consumer proxies (using pact tests that use mock providers) and the provider side has an additional functional test that uses the consumer contracts to prove that the consumer and provider are in sync. that's it. so: • make sure you have a consumer-side proxy that represents the provider (this is code that ends up in production. it is not fake code). it should only proxy the endpoints the app cares about • make sure you have provider-side tests that use the pacts (contracts) generated by the consumer tests. at the very least, the provider team should have their own consumer test that uses all the provider endpoints so they have a strong/tight starting point for their contract tests

Current Pact Setup (POC)

for the POC, having a separate QA repo is fine, but don't do that IRL. all your CT tests should go where all your other tests live; you don't need to separate them.

• Consumer tests:

-Pact consumer tests written in the QA repo

-Requests are constructed manually (HTTP calls)

-Verified only against the Pact mock server

-No real frontend component or business logic involved

good.

Provider tests:

• Provider verification tests also live in the QA repo

• Verified using:

-In-memory DB

-Fake/local server

• Not verified against the actual deployed provider base URL

not good. the provider tests should be against an actual running instance of the provider (if all you are using is Pact and not bidirectional contract testing). mocking out the provider dependencies means you don't know how the real service will behave. that pretty much breaks the pact model.

Core Concern

> The contracts are being validated in isolation, not against the actual consumer and provider implementations.

remember, you are not really testing the consumer. you are testing the consumer's connectivity to the provider. you need the mock server for the consumer test, but using a mock backend for the provider test means you still have no confidence in the results of the test. don't do that. 🙂

My Questions-

1. Is it possible (or recommended) to verify Pact contracts against real consumer and provider logic while keeping ownership with the QA team?

i can see another group being charge of certain kinds of testing, but contract testing should be squarely with the original developers of the provider and consumer. you are not shifting left if someone further up the pipeline is responsible for pact tests.

2. Are there any established patterns where:

• Consumers remain untouched

• Providers remain untouched

• QA still owns contract definition and verification

i'm not sure i totally understand. in a test-driven environment the consumers and providers aren't touched, but the tests the prove their stability might change depending on whether or not a consumer's expectations for the provider have changed or if the provider is releasing a new version/bug fix of the service. i am not sure if QA is the right place for ownership. they can certainly own the pacts, but you want to run the pact tests during dev as well as the succeeding environments where you deploy your code.

3. Would approaches like:

• Running provider verification against a real provider instance in a special “contract-test” mode

• Using ephemeral environments / in-memory databases

• Executing consumer tests through real frontend service layers

be considered valid and scalable?

you should run your provider verification against an actual running instance of the provider. if a provider has a lot of dependencies that could be a problem, but the point is to confirm that the consumer-created pact actually reflects reality. i'm not sure what you mean by:

Executing consumer tests through real frontend service layers

What are you trying to accomplish by doing that?

4. From a Pact philosophy perspective:

• Is a QA-owned contract testing model like this anti-pattern, or

• Is it acceptable as long as contracts are published and verified correctly?

The end goal is always to run a successful tests so you increase your confidence in your deployments. how you get there will depend on your own workflows and internal requirements.

5. In real-world micro-frontend + microservice ecosystems:

• Who usually owns Pact tests?

• How is trust maintained between teams?

I can't speak to either of those. my expectation is that the devs who write the front end are responsible for the consumer-driven part (which includes things like the OpenAPI files, if available) and the provider devs need to run their tests against whatever is in the pact broker at the version level they are testing. that is a very loose way of thinking about it. i hope this does not confuse things more...

I won't echo too much the very good points that Carlos has made already, but I will reinforce a few key points. I think the main issue is that Pact tests should test the actual consumer and provider logic, not some mock/duplicate version of it (as you've identified yourself). Who owns Pact tests? This is typically best owned by the team that owns the application (consumer or provider). The Pact tests are always meant to validate the actual interactions between the consumer and provider, using real data structures and real endpoints, in scenarios that the actual applications would use. If a QA team owns the Pact tests, there is a real risk that the tests will drift away from the actual implementation, defeating the purpose of using contract testing in the first place. Pact tests should be thought of as an extension to your existing test suite, essentially as a step in between unit tests and end-to-end tests (e.g., like this diagram). Verifying against real implementations It is core to Pact's philosophy to verify Pact contracts against real consumer and provider logic. The idea being that, at least in principle, the Pact tests should be able to run against real instances of the consumer and provider applications. In practice, there's typically some mocking involved. For example, a consumer's requests for a user's profile information will likely require authentication tokens, which may be provided by an external auth service, and also the provider may need to connect to a database. It is perfectly acceptable to mock out these external dependencies so that the auth token is always valid, and the database is pre-populated with known data. This is where provider states come in handy, as they can ensure that

token-123-abc

is valid and that the 'Alice' and 'Bob' with user ID '42' and '1001' exist in the database. To be clear, the mocking should only be for external dependencies, ensuring that the actual consumer and provider logic is being tested. There's no point mocking out the consumer or provider themselves, as then you are just testing the mocks, not the real implementations. You mention in your post that the requests are 'constructed manually'. This is a bit of a red flag, as this means you are just testing the QA team's implementation of what the consumer presumably does, rather than the actual consumer logic itself. To answer your specific questions:

Is it possible (or recommended) to verify Pact contracts against real consumer and provider logic while keeping ownership with the QA team?

I don't really think this is a good idea. Pact is consumer-driven, so the consumer teams define the contracts, and the provider teams should verify against them. QA's role should be more about ensuring that the process is followed, rather than owning the tests themselves. Depending on your organization's structure, QA could help implement the Pact tests, though that would typically be done in collaboration with the consumer and provider teams (especially when it comes to implementing any necessary mocking), as the tests typically live within those teams' codebases. QA could also have a role in reviewing the interactions and ensuring that all necessary scenarios are covered. The QA team could also help set up guidelines for provider states, as that is a common point of contention (e.g., different consumers may refer to the same provider state in different ways, which places a burden on the provider team to interpret them all correctly).

Are there any established patterns where:

• Consumers remain untouched

• Providers remain untouched

• QA still owns contract definition and verification

While the core logic of the consumer and provider should remain untouched, the tests and any necessary mocking will need to be implemented within the respective teams' codebases. This ensures that any changes to the logic are reflected in the tests. The verification of the contract should be done as part of each team's CI/CD pipeline, as opposed to being owned by a separate QA team.

Would approaches like:

• Running provider verification against a real provider instance in a special "contract-test" mode

• Using ephemeral environments / in-memory databases

• Executing consumer tests through real frontend service layers

be considered valid and scalable?

Using ephemeral environments or in-memory databases is a common practice to ensure that the provider can be tested in isolation without relying on external systems. If that is what you mean by "special contract-test mode", then yes, that is a valid approach. Note that any 'special mode' should still run the actual provider logic, just with mocked dependencies. It should not be a different code path. Executing consumer tests through real frontend service layers is generally not necessary for Pact tests, as the focus is on the interactions between the consumer and provider, rather than the full end-to-end flow.

From a Pact philosophy perspective:

• Is a QA-owned contract testing model like this anti-pattern, or

• Is it acceptable as long as contracts are published and verified correctly?

I would say that it is an anti-pattern. The core idea of Pact is that the consumer drives the contract, and the provider verifies against it. Having a separate QA team own the tests risks creating a disconnect between the actual applications and the tests.

In real-world micro-frontend + microservice ecosystems:

• Who usually owns Pact tests?

• How is trust maintained between teams?

Typically, the consumer team owns the consumer-side Pact tests, which also serve as the source of truth for the contract, and the provider team owns the provider-side verification tests against those contracts. The Pacts themselves are shared via a Pact Broker, so both teams can see the contracts and their verification status. I would not say that they are 'owned' by any single team, but rather collaboratively maintained, and help build trust between teams. If a Pact test fails, it is a signal that either the consumer or provider has changed in a way that is incompatible with the other, and both teams need to work together to resolve the issue (either updating the consumer expectations or the provider implementation). This collaborative approach helps maintain trust between teams, as they can see that any changes are being validated against the agreed-upon contracts.