📣 Introducing PactFlow’s AI Test Templates + 5 New Languages for Contract Testing AI Generation! 🚀 We’ve recently dropped a few major features to PactFlow’s AI capabilities that I wanted to share with you all: Test Templates and 5 new languages. If you’re using Pact regularly and are looking for ways to accelerate adoption across your teams, PactFlow’s AI features are worth checking out. 🎯*Key Capabilities and Benefits:* 1. Test Templates improves consistency and efficiency, reducing additional manual refactoring work + better “one-shot” test generation: a. Specify Code-Based Test Templates – Provide a local code-based template to use as a basis generated test output. b. Guided Templates – Include additional prompts or instructions to target additional use cases, or further customise output. c. RBAC Integration – Restrict template usage with PactFlow’s role-based access controls. 2. New Language Support - Generate tests in Go, .NET, Kotlin, Swift, and PHP, in addition to Java and JS/TypeScript. 📚 Dive Deeper • Documentation: https://docs.pactflow.io/docs/ai/ • Get hands-on with our workshop: https://docs.pactflow.io/docs/tutorials#use-test-templates-with-ai-augmented-contract-testing-in-pactflow 👉 Show me! Read the blog and watch a short video showcasing the feature: https://pactflow.io/blog/ai-test-templates/. AI features are enabled on all plans - including trials - if you’d like to test it out (start here). 🛣️ What’s next? We’re currently working on Code Review, and will soon turn our attention to MCP support (for better IDE, tool and agentic AI support). Have something you’d like to see there? Reply to this thread, DM me or create/comment on an issue on the roadmap.

Not sure which channel this should go in, but I had a small issue with Pact using the Cypress adapter I had a question about. We use bi-directional contracts with Cypress to generate pacts on the frontend consumer. One of our providers uses a

API Base URL

in their OAS. When we try to generate Pacts with Cypress for it on the frontend, the entire path (include that base URL) is provided as the consumer contract. The issue is, Pactflow doesn't seem to match it with the base URL and were having to strip it from the JSON before pushing it up to Pactflow. ie • Consumer pact states the path is

service/v1/endpoint

• Provider states the base url is

service/v1

and the endpoint is

/endpoint

• Pactflow marks the two as incompatible UNLESS we strip the

service/v1

from the JSON generated by the Cypress Pact adapter before we push it to Pactflow Any ideas of a better solution that stripping?

Hello, this is more about Contract testing overall. We have a pair of services that work together: an Ingress service (proxy), which provides authorization, and then an implementation service that does the actual work. Any client will simply call the Ingress service, which will authorize the caller, then pass the request along to the implementation service. From a contract testing standpoint, the general rule would be to define contracts between the outside consumer and ingress, and then between ingress and implementation. But practically, that doesn't really make sense. My general idea would be to treat the two services as effectively one service, but then I'm not sure how to set that up for proper testing. But one problem at a time. 🙂

Hi 👋, do we have any examples for pactflow contract tests kafka event driven systems using Python?

can someone help verify if the pact.io website is broken? Or is it just me

https://pact.io/

it seems like maybe the JS is broken on the page, and doing stuff like clicking

view on Github

doesn't work for me

Hello, Is there a way to express that a response should contain a particular key, but that its value should be an opaque Json object? I appreciate that pact is not really designed for pass-through scenarios, but wondered if this could still be expressed.

hello i see

interactionId

in HAL browser, not user-friendly names. is it something new-ish ?

"testResults": [{
      "interactionId": "0eac6b0ba31719c60b6d5d0c1a5a1ceab75943c2",
      "mismatches": [{
          "attribute": "body",
          "description": "Actual map is missing the following keys: reason",
          "identifier": "$"
        }],
      "success": false
    },... {
      "interactionId": "30ac1652bdc5ce4d8109d0ccabb4b99f6adc0013",
      "success": true
    }]

What is the recommended approach to force a deployment of a specific version (regardless of consumer or provider verification status) when

can-i-deploy

fails? I'm exploring the following workaround — is this a valid approach? 1.

create-version

2.

publish-pact

/

verify-pact

3.

can-i-deploy

(fails) 4. force deploy anyway (with override flag or manual trigger) 5.

record-deployment

Are there any risks or better alternatives to this flow?

Attempting to use Pact with rust & gRPC. Having trouble when it comes to multiple synchronous messages to the same endpoint but with different request data. The mock server receives a request and responds with the response for a different request message. Example implementation here: https://github.com/MeatballSub/pact-help

Hey, A quick question. Does Pact support GitLab CICD integration? I could find anything related to GitLab CI integration in the documentation as it's all about GitHub.

For those of you looking for a practical, hands-on course on contract testing with Pact, my self-paced, online video course is now complete and available at https://ontestautomation.teachable.com/p/practical-contract-testing-with-pact Course features: _ Dozens of short, to the point instructions videos, with subtitles and transcripts _ Quizzes to test your theoretical knowledge about contract testing _ Hands-on programming exercises to put that knowledge to the test and write and run your own contract tests and make them part of a build pipeline The exercises are available in Java for now. I'll start adding exercises in other languages very soon, starting with C#, then JavaScript / TypeScript. To celebrate the (long overdue) go-live of this course, you can use the coupon code 50PERCENTOFF at checkout for, you guessed it, 50% off the regular price of USD 149. This coupon code is valid until Sunday, July 13, 11:59 PM CEST. (Posted with permission from the Pact team)

Hello. I have a question regarding running provider verification of recently published pacts for different deployments. How can you run provider verification of PACT changes against versions of the provider that have been deployed to other environments? At the moment, we are just running provider verification via a webhook against what's on the latest version of the main branch.

Hi all - we have some unit tests using Pact via FFI for contract verification and I'm trying to improve their performance. The Application is in C++ and we run the tests via GTest. We use an updated fork of Pact's C++ client which uses FFI under the hood. Each test does the following - 1. Creates a provider instance 2. Instantiates a custom plugin 3. Performs verification Rust is not my area of expertise, so apologies if this isn't correct but it looks to me like each call to pactffi_using_plugin will block the client thread for at least 0.5s, so each of our unit tests is taking at least that long to complete.

let result = RUNTIME.block_on(async {
          let result = load_plugin(&dependency).await;

          // Add a small delay to let asynchronous tasks to complete
          sleep(Duration::from_millis(500)).await;

          result
        });

I've tried using a fixture to make the plugin and provider instance persistent across multiple tests, but haven't had much luck (it looks like there's some state not being cleaned up between unit test runs - or maybe ths issue is with our plugin?) - the first test passes but subsequent ones fail due to contract verification failures. I can probably provide a minimal example but I thought I'd ask first in case you had any ideas. Many thanks!

Hi In my org we had done an alignment to adopt pact as a contract testing framework, which will help us write the pact tests which then eventually help us eliminate any contract breakage between services in production or release branches. Now I have multiple questions regarding consumer and provider side of things: Consumer: 1. In the consumer application, should i publish pacts for each version (version being a commit id when the squashed commit merges in any branch) and branch (develop, release branch 1, release branch 2) OR should I only publish when the pact changes with the version and branch name? 2. When writing pacts in the consume side, what naming convention should we follow for consumer and provider. If I choose to use consumer name as the actual service name, it will be too generic and all set of interactions for that consumer service and the provider service will all go into that pacticipant. Also will I get this visibility of which interaction’s verification has failed in the pact broker OSS version ? Provider: 1. Should a provider write pact test without the consumer actually implementing their pact tests ? If yes, then lets say the provider writes the pact test for their service and in future the consumer also writes the pact test, uploads the pact to pact broker and for some reason the provider pact tests (verification starts failing) starts failing in this case. Should we stop the provider PRs in this case ? 2. In our current provider verification, we have passed consumer version selectors as “matchingBranch:true” since all our services in the org follow the same branch name convention and the release branches are cut at the same time, which then means that the provider will only pull in the pact for that particular branch? Is this the latest pact from that branch (latest version of consumer indirectly) ?

Hello. Quick question. For events, is there any guaranteed order of the events that get emitted?

Hi, I'm utilizing the capability of pact SDK to build a contract broker in my company for internal rpc services. The broker I'm building aims to support contract publishing, contract retrieval and response verification. A quick question: our company uses a set of self-defined rpc protocols, what's the best practice of applying pact to our company's rpc protocols? Does pact directly support that? Or should I use an adapter layer to first transform the rpc response to the model that rpc can identify, and then use methods like compareSynchronousMessage() to process verification?

Hi, is it possible for multiple consumers to share a common contract with the same provider? I mean if they call the same API with the same expectation.

Hi, I'm thinking about such a scenario for RPC consumer and provider: if consumer has pulished contract to the broker, and later in the integration test stage the consumer need to mock the dependency of the provider, can we directly generate mocked response based on the interaction rule in the contract so that the consumer don't need to write mock tests? I think it would be a benefit for the consumer, and a good point to persuade them to adopt contract testing. Has anyone tried this approach?

Is there any code demo of consumer test for non-http synchronous messages case? Prefer Java. Thank you!

Looking for a bit of advice on how to handle stringified json inside of a message body and regex against a couple of the keys. What I was trying to do is something like this

it(`consumes a valid ${type} message`, async () => messagePact
         .expectsToReceive(`a valid ${provider} ${type} message`)
         .withContent({ Body: regex('tenantId', 'tenantId') })
         .withContent({ Body: regex('userId', 'userId') })
         .withContent({ Body: regex('verb', 'verb') })
         .withContent({ Body: regex('actor', 'actor') })

But the contract will expect the Body to be

Body: 'actor'

{
      "contents": {
        "Body": "actor"
      },
      "description": "a valid assessment-artefact-service xapi message",
      "matchingRules": {
        "body": {
          "$.Body": {
            "combine": "AND",
            "matchers": [
              {
                "match": "regex",
                "regex": "tenantId"
              },
              {
                "match": "regex",
                "regex": "userId"
              }
...

If I manually delete the contents from the contracts, then the pact is valid and passes. I've got about 300 queues running like this and refactoring an entire architecture isn't feasible.

Hey, following this documentation https://docs.pact.io/pact_broker/webhooks#example-cicd-and-webhook-configuration there seems to be an approach to providing a webhook that lets the CI know when to make a call to

can-i-deploy;

however, this approach only works when the

contract_requiring_verification_published

event is triggered. it there a way to call a webhook that lets CI call

can-i-deploy

when there is no change to a contract?

blobwave Happy Friday everyone! Do you have trouble with your sec-ops teams giving you grief about ruby processes on your machine, when all you want to do is publish a pact to a broker? 👮 Do you wonder why a wee cli, weighs in at circa 40mb? Because distributing ruby is sadblob I am after willing volunteers to give the rust rust rewrite of the pact_broker-client a whirl. https://github.com/YOU54F/pact-broker-cli Drop us a shout in the 🧵 if you are keen 👇

👀 https://pact-foundation.slack.com/archives/C9VECUP6E/p1754972602066339 🚀 I know this has been a long time coming, but the effort, diligence and attention to detail in the latest release of Pact Python is chefkiss . Amazing work @Joshua Ellis , I’m sure the Python community will love this 👏

Happy Friday everyone blobwave

Hi guys I have a question: some engineers in my company feel writing Pact DSL not convenient and don't want to do it. I've tried to provide a prompt template to generate Pact DSL by LLM automatically, but hard to achieve compile error free. Anyone has thoughts on it? Really appreciate for any advice.

Hi PactFlow team — I have a meeting with @Rohit Thadhani in ~30 mins but haven’t heard from him or received a calendar invite. Could someone help check with him if we’re still on? My team and management are waiting on confirmation. Thanks!

This is a general question about matching, but applies to Pact-JVM. How do I specify/match an empty JSON array. We have a response that looks like:

{
  "destinations": [],
  "cities": [],
  "airports": [
    {
      "code": "MSY",
      "name": "Louis Armstrong New Orleans International Airport"
    }
  ]
}

I want to match that "destinations" and "cities" are indeed empty lists. I am trying to use

maxArrayLike("destinations", 0, example)

but I get an error on the Consumer test complaining that I either cannot leave that field empty, or that the example of 1 doesn't match the expected size of 0.

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.

Hi guys, I am promoting contract testing in my company, and need more strong evidence to persuade other engineers to adopt it. Can someone share some context and scenarios about why you used contract testing, and what pain point it resolved in your company? Really appreciate. 🙏