Hey @Holly Cummins, I wondered at what point you might join us after all the awesome presentations - welcome!

Is the can I deploy tool available with the OSS version?

Prove me wrong: Pact (or any form of consumer-driven contract testing) provides little to no value for testing GraphQL APIs. According to https://docs.pact.io/faq/convinceme, “OpenAPI can be used as a contract testing framework in a similar way to Pact”. I would make the argument that the same applies for GraphQL. In both cases, the APIs have a schema with strongly typed definition of field names, types, etc. Testing guidelines on https://docs.pact.io/consumer recommend loose matching (field names and data types only). The example on https://pactflow.io/blog/contract-testing-a-graphql-api/ follows this approach. Assuming I have a way to ensure that there are no breaking changes to the provider’s schema (e.g. by static analysis), what value at all is this contract test providing? Again, please prove me wrong. My organization has all the problems that contract testing purports to solve. I want to make a case for adopting it. But so far I am disappointingly unable to. If I were to follow recommended practices, it would require a LOT of development overhead to implement consumer driven contract tests that provide little to no value given the existence of a strongly typed API with prevention of breaking changes already in place. The only case I can see right now for consumer driven contract tests providing value is if we can use them in place of functional / integration tests for our front end layer. Right now these are heavily reliant on VCR cassettes but are not providing value because the cassettes are brittle and not frequently re-recorded. If we could use contracts in place as the mocking layer, that would ensure that the mocking layer of the consumer integration tests is in sync with the actual APIs. However, that approach is strongly discouraged in https://docs.pact.io/consumer, especially in the video on that page; to quote presenter: “the teams that have done it have really regretted it”.

Is there a way to ensure that when a consumer's behaviour is modified, the pact gets updated? We are introducing contract testing, but I'm worried about the case where a developer changes the consumer's real interactions with the provider but forgets to update the contract. So the functionality could be broken, but the contract test would still pass. I haven't seen this risk mentioned anywhere, so maybe I'm missing something

Hi, if I use the contract_requiring_verification_published webhook lets say I have the following scenario: 1. consumer contract asks for fields that dont yet exist in provider 2. contract is published 3. webhook verifies it 4. verification fails 5. when we run the consumer pipeline again, the contract has not changed, so it will never be verified again ? 6. provider implements the new field how does the contract get re verified for the new provider version? I'm sorry if this is a stupid question. I don't want the webhook to simply trigger every time a contract is published whether it changes or not because that would be excessive. I guess I am wrong about step 5, it should be verified again when a new version of the provider is built, but if I don't see this behaviour, what has gone wrong?

Hi Team! Could you please let me know if

--state-change-url

of the pact_verifier_cli accepts several urls? For example, if there are two provider states endpoints as

/app_one/pact/provider_states

and

/app_two/pact/provider_states

Based in Melbourne 🇦🇺*? Join upcoming in person event with the Pact/PactFlow crew at DiUS on Thurs 4 May at 4:30pm.* Expert speakers will discuss the benefits of automated testing and deployment strategies, including CI/CD practices to build the confidence to execute. Plus, there will be beer, pizza and swag to be won and a bunch of your Aussie-based Pact/PactFlow team will be there too (@Ilia@Matt (pactflow.io / pact-js / pact-go)! 👉Register to attend 👈

Hi, I already wrote in the pact-jvm channel, but I guess it's also a general question, so I'm trying here as well. I am looking for a way to specify that we expect either attribute A to be present, OR attribute B. Is there a way to specify this with pact? I have tried with the combine : "OR", but I suspect this is rather for specifying multiple rules for one attribute... Would appreciate any help!

Hi, I'm trying PactFlow on my local machine. But I'm not able publish my contract. The publish command: npm run pact:publish, throws error '.' is not recognized as an internal or external command

At a talk I gave last week, someone asked a question which I didn’t feel confident to answer: “How would you handle a situation where the consumer, C, called service P1 and then passed the results onto service P2? C only cares about the result of the call to P2.” I can see how to contract test P1, but I’m not sure how to contract test the transitive nature of the relationship. I’d appreciate any perspective you might have.

Hi again everyone. I asked a question a couple of days ago, and I am almost done implementing the tests with different provider states as suggested by you! However, if I could get some more support I would be very thankful. I am currently adding datetime validation for my pact, but for some reason pact seems to add 2 hours to the example I provide:

root.datetime("lastModifiedDate", DATETIME_FORMAT, DateUtil.toInstantFromDatetime("2022-06-27T12:30:10.767Z"))

JSON output from this is 2022-06-27T143010.767Z. Can someone explain to me how I can fix this?

Hi all, random question. When the webhook exists in both consumer and provider pipeline, how do you prevent an infinite loop of calling the webhook when the other pipeline is ran? one method I thought of was using a separate branch that does not include the webhook on the 'called' pipeline. However if its calling a separate branch it will be generating a contract that is not on master which may be old and not current. What is the best practice for this scenario?

Hello! Has anyone tried contract testing between micro frontends ?

Hello, is there any documentation that explains Pact in the context of a BFF or an application that is a consumer and a provider at the same time?.

Next episode has just dropped! Graphql and Web3. https://www.pactman.co.uk/contract-testing-podcast

Hi everyone, quick question, does pact consumer/provider version have a character limit?

Hi, pact-foundation team, I recently joined the community and need some blob help I see in the pact-ruby-standalone/releases/tag/v2.0.0 that breaking changes are mentioned for naming conventions and I can confirm that the old consumer tests that used to work with previous versions, are not passing any more with the latest version 2.0.0. 1. I would like to understand why the naming conventions change impacts the test execution 2. there is a way to specify the version for the brew install command line? currently, the latest version is pulled. there is any other solution/suggestion to fix this? thankyou

Hi, I am getting this error when i try to load the libpact_ffi.so in erlang vm that i got from pact_ffi release page:

"No driver init in dynamic library"

I have tried multiple ways to load the pact ffi shared library but getting errors similar to the above one, any help would be appreciated. Thanks in advance!

Hey team 👋 I'm almost certain that the answer is no, but wanted to triple check before I share with my team. When you write consumer side tests, is it possible to specify multiple provider states in the given block ? For example, how would you go about creating a given block for a scenario that required --> given "a product with ID 10 exists" & "a user with ID 5 exists" ? Any help appreciated. Ta!

Hi everybody - nice to meet you! 🙂 when we use the _pactBuilder to mock a service, on which endpoint do we create the server? and is that configurable? (host + port)? Thanks!

2. when writing contract tests - do you recommend using the actual deployed service (always running) or starting up the service on the spot?

Hey all 👋 I have some questions about migrating from tags to native environments/branches with pact-broker, since the diamond step still prefers to use tags: On a PR branch, the environments docs recommend running

can-i-deploy

against all environments on the main branch, which makes sense to me, but: 1. From that PR branch CI pipeline, do we also need to run

can-i-deploy

against a main branch to catch any merged-but-not-deployed changes? 2. Is it still recommended to setup a webhook to trigger a provider verifications with native environments/branches? Since that doesn't sound like it recommends actually deploying those services changes from that

Hi. I am just looking at the provider-example https://github.com/pactflow/example-provider/blob/master/src/product/product.providerChange.pact.test.js. This might be a stupid question but I just want to confirm is this just using a dummy (mock) provider? In a real provider contract test would this be making calls to an actual api?

So many 🌮 s for @Yousaf Nabi (pactflow.io) for this incredible investigation and diagrams of the Pact ecosystem: https://github.com/pact-foundation/devrel/issues/10

Hi, I am currently using the C++ FFI to generate PACT contracts for some synchronous interactions and trying to understand why I am seeing multiple entries in the contract for identical request-responses. Have posted example interactions below

auto syncInteraction1 = pactffi_new_sync_message_interaction( pact, "Interaction");
pactffi_given( syncInteraction1, "Given" );
pactffi_upon_receiving( syncInteraction1, "Upon receiving" );
pactffi_with_body( syncInteraction1, InteractionPart::InteractionPart_Request, "application/json", R"({"jsonrpc":"2.0","id":{"value":3,"pact:matcher:type":"type"}});
pactffi_with_body( syncInteraction3, InteractionPart::InteractionPart_Response, "application/json", R"#({"jsonrpc":"2.0","id":{"value":3,"pact:matcher:type":"type"}})#");

auto syncInteraction2 = pactffi_new_sync_message_interaction( pact, "Interaction");
pactffi_given( syncInteraction2, "Given" );
pactffi_upon_receiving( syncInteraction2, "Upon receiving" );
pactffi_with_body( syncInteraction2, InteractionPart::InteractionPart_Request, "application/json", R"({"jsonrpc":"2.0","id":{"value":4,"pact:matcher:type":"type"}});
pactffi_with_body( syncInteraction2, InteractionPart::InteractionPart_Response, "application/json", R"#({"jsonrpc":"2.0","id":{"value":4,"pact:matcher:type":"type"}})#");

The above 2 interactions are the same except that the id field(in the request/response) has different values but is matched by type. So, I was expecting this to generate only 1 entry in the contract for both interactions which the provider can verify. But in the contract, there are 2 entries. I suppose this is because there are 2 unique keys generated for each of the 2 interactions? Any ideas how we can get around this so we can have only 1 entry in the contract for such duplicated interactions when using the C++ FFI to write PACT consumer tests would be much appreciated.

Hi .. Do we have any case studies or POCs done to integrate PACT with Azure CD pipeline?

ralph wave How do everyone, happy Tuesday!

Is https://github.com/pact-foundation/pact-cplusplus still supported? I attempted to install per the README.md, but I'm apparently not downloading the conanfile.txt. conan remote list conancenter: https://center.conan.io [Verify SSL: True, Enabled: True] pact-foundation: https://pactfoundation.jfrog.io/artifactory/api/conan/pactfoundation-conan [Verify SSL: True, Enabled: True] conan install . --build missing ERROR: Conanfile not found at /home/harveys/pact/conanfile.txt

Get contract testing certified! every days a school day The team at SmartBear have created a three-part introduction to contract testing course for developers who are new to contract testing (and their teams) to learn the basics, covering: 1. Introduction to contract testing cool dog - what is it, why it is needed (vs over-reliance on E2E tests) 2. Introduction to Pact pact logo white - what it is, how it works, how to get started and automate 3. Introduction to PactFlow pactflow - compare Pact OSS vs PactFlow, benefits of PactFlow - exclusive features such as directional contract testing and more for enterprises They are short, bite-sized and accessible courses with exam questions so you’ll finish up with a contract testing certification - all from the team that created Pact and PactFlow! To take the courses, simply sign up here https://smartbear.com/academy/pactflow

Hi… does someone has implementation example of consumer test with Vitest? Thank you