Idea: prod pact. A bit of middleware that will log if you're about to send a request or a response that doesn't match any pact interaction

Can any one help me to design which parts i should do a contract test with Now we have microservices , FrontEnd which is a mobile apps and web and there are also an api gateway which handles requests between microservices and FE for which parts i should add my contract test in to get best test coverage ?

Hi there, I'm trying to run a test scenario where a parameter is passed in an invalid format (and it should throw a 400), but it fails with the error message

with 30000 ms timeout for Pact

. I've tried to increase the timeout (quite significantly but it still fails with the same message). Is there any way to check why it times out? It seems due to a promise that doesn't resolve... Also it seems to be specifically when looking to get the provider to respond with status 400 🤔

Hi folks, We (my team) have a react consumer and a ruby provider, and we’re doing work refactoring one of the endpoints on the provider, by removing unused attributes from the returned JSON in order to improve performance. I want to write a test that would validate that after changes to the provider, the relevant component on the consumer can still render correctly. My idea so far is like this: 1. Update contract test on consumer to match what I expect the backend to return 2. Update my component’s unit test on the consumer to ensure the component will render correctly with the updated backend data 3. Once everything validates, make changes to the backend. Does this sound correct? If so, is there a smart way of not having to maintain two sample API responses on the consumer side (one for the contract test, one for the component’s unit test?) In other words, is there some best practice to reuse data setup for a contract test in a component’s unit tests?

Hey everyone, quick question: I am using the

pact-provider-verifier

and I installed it through

gem

. On my use case I needed to use a header called

response-format

(all lower case)but it seems like when pact-provider-verifier does the request it changes the header and capitalizes it to

Resonse-Format

, is there a way to prevent this from happening and being able to use the header all lower case?

Hi there 👋 I have a quick design question regarding the

fromProviderState

mechanism. Its not language specific, but I'll use the JVM examples. A frequent situation, also shown in the docs, would be that a consumer is asking for a specific situation:

builder.given("product with ID 10 exists")
  .uponReceiving("get product with ID 10")
  .method("GET")
  .path("/product/10")
  ...

In this example the consumer had to came up with an ID that might exist for a product. (And the provider will then have to adhere to that, making product 10 available). Would this also be a valid application for

fromProviderState

to let the provider decide on the ID of an existing product? (All examples I found in the docs only relate to autogenerated IDs that can not really be picked by the consumer without making life hard for the provider. And they are also mostly focused on using

fromProviderState

for the response part, i.e. after

willRespondWith()

.) I.e. should we write this code instead as

builder.given("a product exists")
  .uponReceiving("get that product")
  .method("GET")
  .pathFromProviderState("/product/\${id}", "/product/10")
  ...

with a provider having a state like

@State("a product exists")
fun createProduct(params: Map<String, String>): Map<String, Any> {
  val product = ... // maybe create that product in the DB or something

  return mapOf("id" to product.id)
}

Thanks in advance and cheers 👍

I have a follow-up question on

fromProviderState

design. Where do I ideally draw the line when to use it for argument details that the consumer simply does not care about. Lets say the pact is testing a

hello world

response and the API also requires a somewhat unrelated header that the consumer is supposed to send, maybe

X-Locale: de

. Now, for the test and pact this argument does not matter, any valid country-code would suffice,

fr

for example. Should the pact on consumer side now explicitly demand

de

, using

headers("X-Locale", "de")

or let the provider decide on this with

headerFromProviderState("X-Locale", "${anyValidLocale}", "de")

? This question goes even further. Lets say we have to send a complex DTO body, but for the particular pact only one value in it actually matters. Should the rest of the DTO be given by the provider state or should the consumer just specify the full DTO, even though majority of it doesnt matter? Essentially, I am looking for ways to signal to the provider that something was not picked due to any particular reason, but could be anything. So that the provider clearly knows which part of the contract is actually important to the consumer.

Hi there! I have a question on how Pact / bi-directional contract testing can be beneficial when developing APIs where providers generate new specs when introducing breaking changes and consumers consume it via an HTTP query parameter? E.g. REST API have a form of

GET /path/to/resource?version=2021-09-21

with the parameter targeting a specific date of the API specification. In other words, when new API breaking changes get published, API provider creates completely new OpenAPI specification that consumers have to switch to if they want to target the latest version. The old versions are being supported until a certain deprecation date. You can read more here, if you need a more detailed explanation. How would the consumer and provider contract testing flow look like in such scenario?

hello! wanted to repost my question in #C9VBGLUM9 here as well. having some issues configuring my consumer tests. any advice would be greatly appreciated! https://pact-foundation.slack.com/archives/C9VBGLUM9/p1660526266380169

curious what ya’ll think about needing or not needing contract tests when the provider is graphql. seems like the graphql schema can be a good enough proxy for a stand-in contract test. just want to make sure we use contract testing in the correct places

Hi In the following articles "contract testing using json schema" is explained from a theoretical point of view: contract-testing-using-json-schemas-and-open-api-part-1 contract-testing-using-json-schemas-and-open-api-part-2 contract-testing-using-json-schemas-and-open-api-part-3 If I'm not mistaken Bi-Directional contract testing is a kind of contract testing using json schemas. In the articles above it is mentioned that one of the advantages of this type of testing is the possibility to test the provider as blackbox. For example in the dotnet Bi-Directional contract testing workshop ( https://github.com/pactflow/example-bi-directional-provider-dotnet ) the schemathesis tool is used to verify the provider API in a blackbox manner as follows (in this case the provider is running on the docker host on port 9000 and the tool access it from within the docker container to test it): docker run --net="host" schemathesis/schemathesis:stable run --stateful=links --checks all http://host.docker.internal:9000/swagger/v1/swagger.json > report.txt Of course it has advantages to be able to test a provider in this blackbox manner but what if most of your microservices have external dependencies? Can you use this approach then? In the workshop mentioned above you have to send both to Pactflow server, the swagger.json file (which is generated during the build phase in the workshop) and the report.txt file which contains evidence that the provider API was tested (by that blackbox test mentioned above). The problem is what if you can’t easily get your provider with lots of external dependencies running in the pipeline. In that case the generation of that provider API test evidence gets quite difficult. You would have to have access to the code to make sure that your external dependencies are mocked away during the blackbox test. But being forced to have access to your code while you want to perform blackbox tests kind of defeats the advantage of blackbox testing. I have tested the Pactflow workflow to see whether the system could work without the need to publish the provider API verification evidence and by only publishing the swagger.json. It turns out that the consumer’s can-i-deploy is happy with provider’s swagger.json being published alone and can be deployed without the provider having its API test evidence published. But the provider’s can-i-deploy does not allow it to be deployed as long as its API test evidence is not published. Of course this all makes perfect sense. But what if you really want to take advantage of blackbox testing but you can’t get your provider with lots of external dependencies up and running in the pipeline. What if you are mostly interested in the compatibility between your consumers and providers and not so much about testing your providers themselves. Is there a way to work with swagger.json alone and leave out the provider API test evidence (represented by report.txt in the workshop example above)?

Hello, I am new to pact so when experimenting with versioning, I see that when I run a provider validation, it seems to only validate against the latest pact found in the broker. Is this the expected behavior? In this matrix, there are 2 versions of the consumer (different content of pact files), but 3 versions of the provider. There is no verification result of the green version of the provider against the blue version of the consumer. However, when i run can-i-deploy on the green version of the provider supplying the blue version of the consumer as pacticipant, I get a failure, is it right?

Question about webhooks for consumer/provider pipelines. TLDR: in thread 🙂

Are there any metrics that can be pulled (or visualised over time) from the open-source pact broker or pactflow. Like, the pass rate of integrations or number of integrations over time? (Not necessarily these but just in general)

Can a provider application upgrade to Pact V3 independently of the consumers? is it backward compatible?

our api responses are usually very big and when running provider verification for multiple consumers we have large logs even with

error

logLevel. How to make it manageable and to be able to debug from those? maybe a flag to not show the actual responses but just the error and differences. or any other tips?

quick question: I have this pact file with the contents. This file is in my local machine path:

/Users/srentala/Desktop/Pact/pacts

{
  "consumer": {
    "name": "test-consumer"
  },
  "provider": {
    "name": "test-provider"
  },
  "interactions": [
    {
      "description": "a request to get the machine IP",
      "providerState": "a endpoint to get IP",
      "request": {
        "method": "GET",
        "path": "/product"
      },
      "response": {
        "status": 200,
        "headers": {
          "Content-Type": "application/json; charset=utf-8"
        },
        "body": {
          "ip": "81.96.249.131"
        },
        "matchingRules": {
          "$.headers.Content-Type": {
            "match": "regex",
            "regex": "^application\\/json"
          },
          "$.body": {
            "match": "type"
          }
        }
      }
    }
  ],
  "metadata": {
    "pactSpecification": {
      "version": "2.0.0"
    }
  }
}

I am running the following command to create a mock server using Pact :

pact-mock-service --consumer test-consumer --provider test-provider --port 1234 --pact-dir=/Users/srentala/Desktop/Pact/pacts

but on hitting the endpoint from Postman, it gives following “no interactions found” . What am I missing here?

Hello! We are beginning to incorporate

record-deployment

as part of our CI/CD process. If a provider version (git sha) was never required to verify a pact should we still use

record-deployment

when deploying that version of the provider? We are only using consumer driven contract testing, and leverage the

contract_requiring_verification_published

event so the consumer in some cases never triggers a provider build because the content is the same. Should we be leveraging

create-or-update-version

first in this case?

Hello Team, What is the general notion while setting up provider states? For example - "A user John Doe with bank account exists", here should we actually create a user and link a bank account? Or is it possible to mock this behaviour?

Hi all, I'm newbie. Please, reference me some course or document about pact to contract testing...thank you

Hi all, Could you please clarify how can I fix Network Error on the http://localhost:3000/error? When I run 'npm start' in the cloned 'example-consumer' repo, I receive the error I repeat as on the video

Hi all, Could you please help me how to fix this error? I have executed 'npm run test' in the 'example-provider repo'. But I have error at the Pact Verification › validates the expectations of ProductService. Please see the screenshot attached. The error is ' Must provide the pactUrls argument if no pactBrokerUrl provided'. I have thus pactBrokerUrl mentioned at PACT_BROKER_BASE_URL: https://zlata.pactflow.io in .github/workflows/ -build.yml -verify_changed_pact.yml

Hi @Matt (pactflow.io / pact-js / pact-go), I have entered echo %PACT_BROKER_BASE_URL% in terminal and the value wasn't returted. Could you please clarify, if I should paste this value in all the files mentioned in the error or there is another way?

Hello! quick question, is there a way to debug why the

contract_requiring_verification_published

event was detected when publishing a pact? the pact content is not changing and I believe we are populating all the required fields. I also see this message beside it

(pact content is the same as previous versions with tags  and no new tags were applied)

Hello! I saw in the pact docs FAQ a topic about points with Swagger, and it said to contact one of the maintainers if you are interested in doing something like generate a Skeleton Pact test code from a Swagger document. Do you already have something thought about this? Who can I contact about it?

Hello All, I have some questions. I am working on setting contract tests for a GraphQL service (provider) using Pact. The provider is a Ruby on Rails app, the consumer is JavaScript. The JS version of Pact was wrappers for creating GraphQL interactions but the Ruby version does not. 1. For the provider (Ruby) do I create state handlers that return the correct GraphQL. where the objects are loaded from say a file or 2. Do I have to: • Have the actual provider running; and • Have to seed the DB with the data elements the tests need Item 2 above being more complicated I am guessing the answer is implement the provider verification as in item 1 above, is that correct?

Hi, team👋 we are using pact contract test and many of our consumers are developed by Perl, is there any official support on Perl language?

Hi.. the 5 min tutorial defined in https://docs.pact.io/5-minute-getting-started-guide. hangs on the “Repl Waking up… ” phase Who can help ?

Hi. I managed to convince my team to give Pact.io a shot. We have a GraphQL provider, and multiple consumers, but focusing on a single one right now. We are working using git flow - feature branches, develop branch that we merge FB to, and then master branch for production-ready code. We have introduced can-i-deploy on develop/master branches, that checks against current environment (

staging

for develop branch, and

production

for master branch). We have noticed a potential obstacle: • have a query

User{fullname}

, • lets assume we want to change that query to return firstName, lastName our initial thought was: • lets change the provider to return

{firstName, lastName, fullName}

• then we are able to make changes in the consumer, and deploy to

staging

• then we are able to remove the redundant & unused

fullName

from the provider, and deploy to

staging

that would work okay for develop branch, but then if code gets merged to

master

, we wouldn't be able to deploy provider (as the currently deployed

production

consumer still requires

fullName

to be passed) and in such case, we are unsure how to proceed.

Free Hands-on Training Tonight (6:30 pm BST) - Pact Consumer Driven Contract Testing Hi Testers 👋 - this evening Grace Tree and I will be hosting the DevOps Playground Meetup in Manchester, UK and Online. After a short consumer-driven contract testing talk, we will be diving right into a hands-on lab. There is no need to install anything locally; it is set up and ready to go in the cloud ☁️. You will get a terminal; a hosted Visual Studio Code editor, and guidance on using Pact through a pre-designed scenario. If you fancy it, here is the link to sign up: https://www.meetup.com/devopsplayground/events/287778275/