Does anybody have an example azure-pipelines.yml for an azure devops ci/cd pipeline with pact? Trying to figure out how hard a pact proof of concept for my team in that ci/cd system would be.

As some of you know already, I've stepped down from maintaining pact-js to focus on other projects (technically last week was my last week as maintainer). The project is in good hands, though! @Matt (pactflow.io / pact-js / pact-go) will still be around to steer the pact-js ship, and I think there might be some more contributions from other familiar faces coming up soon.. It has been several years now since I started maintaining pact-js - so many people to thank - but some specific standouts - @Beth (pactflow.io/Pact Broker/pact-ruby) for giving me my first introduction to Pact on a few post-it notes (possibly on the first day we met), @Boris for initially suggesting we use Pact on a project we worked on together, @uglyog for agreeing to spend the time we were supposed to be talking about other things helping me with some pact-jvm issues, @Yousaf Nabi (pactflow.io) for taking the initiative to get

jest-pact

out of a git gist and into an npm package with nearly 70,000 weekly downloads, and of course my Pact-JS co-pilot @Matt (pactflow.io / pact-js / pact-go) for being an excellent co-pilot, engineer and friend. The whole team of maintainers have always been friendly and fun to work with through our many many discussions, agreements (and sometimes disagreements). The project is in good hands, and I think the Pact user base will only grow in the next few years - especially now that #CLS16AVEE is a thing, making it easier for new and enterprise users to get into Pact. Exciting times! Thanks also to the many Pact users out in the wider community - especially the occasional contributors - shout out to @Artur Neumann for attention to detail and many many helpful PRs, and @Omer Morad for making things idomatic for Nest-JS users. The community of users and contributors keep the project alive, otherwise it would just be us maintainers. You make it all worth it! Finally, when I took up the Pact-JS reins, it was only possible because of the work of the maintainers + contributors that came before me (Tarcio, Michel, and others). Thank you too, past team! Even though I'm focussing on other projects, I still believe in the value that contract-testing with Pact brings to software development, and I'll keep using it (and probably will occasionally contribute PRs, who knows). I'll still be around on slack, but I'll take a break for a month or two to enjoy the sunshine first 😎 Keep on Pacting, friends. Oh, and please remember to put your framework-specific issues in the right channel 🤔😆🥰

When we ruck our spec files, the contract is saved in

/spec/pacts

, but we have to create the directory right, and how do we configure that the pacts are stored there?

🌮 🌮 🌮 for @Adam Rodger (pact-net), who’s kicked off the year with a bunch of major contributions to the #C9UTHV2AD project. I keep wakin up to an inbox that looks like this 😆 Not too far away from a proper Nuget release it seems!

Hi! 👋 I've been reading through some of the pact docs and I am very interested in the auto-generated docs that are viewable in the Pact Broker. It occurred to me that one way to define an API could be the union of all of its contracts. However, documentation seemed to be on a per-contract basis. Is there any support (current or planned) to view some aggregation of all of a provider's contracts in a format that could be loosely seen as an API spec?

Hey. I was watching the and @Beth (pactflow.io/Pact Broker/pact-ruby) said the recommended approach is for the consumer to code against new functionality on a feature branch so it doesn't break the provider. I totally get why this approach solves the problem of not introducing a contract into the main branch until it's ready to go live. However, this pretty much goes against trunk-based development. This is a key practice that has been shown to improve software delivery performance (see the book Accelerate). For reference you can see the DORA page on trunk-based development as well as https://trunkbaseddevelopment.com/ It's great that pending pacts helps solve this, but I am concerned in general that as you develop tools and features for Pact, you're assuming a workflow that actually isn't best industry practice these days. For example, an important workflow we need to support is to put new changes behind a feature flag. We want to test the new pact that's behind this feature flag without causing the provider to have their build break now that the pact has been verified (which is what would happen with pending pacts). I think we can do this with tags (need to try it) but I'm concerned you're moving away from tags to the concepts of branches, deployments and features. In that world, there is no space for scoping a pact and its verification based on a feature flag. I'd love to hear your thoughts on this. Thanks!

Hi, I wanted advice on the best approach for using Pact when you require pre-requisite data. For example, I want to test a success response structure for Service A, but in order to trigger that response I would need to hit multiple endpoints on Service B in order to create data to be utilised by Service A to give a success response. What is the approach here? Do you add setup api calls to run before the pact test to generate the required data? or do you do something in the provider like stubbing out a datasource?

My team is looking to introduce Contract test in our CI/CD pipeline. I was looking for the best strategy here to setup the broker as a first step. what yould be your advice? • Building a Helm chart around the

<https://hub.docker.com/r/pactfoundation/pact-broker>

docker image? • Free trial on https://pactflow.io? • other option? Would appreciate any feedback or input 🙂

Hello I'm trying to implement a pact solution for the multiple dependent microservices scenario A -> B -> C. The most detailed description of the problem and the potential solutions seems to be the following GitHub Gist: https://gist.github.com/bethesque/43eef1bf47afea4445c8b8bdebf28df0#file-index-md What is meant with the following sentence? "Then, in your Pact test for CClient, you can use the same alligator instance as a "link" to tie your stubbing to an artifact that will get verified." Can someone elaborate a bit more on that? "your Pact test": Which pact test is meant here "AB provider test" or "BC consumer test"? "same alligator instance": Is the same subbing instance to be used in both tests? "AB provider test" and "BC consumer test"? Who writes to the shared artifact and who reads from the shared artifact? Thanks

Starting to learn about pending pacts and work-in-progress pacts. Pending pacts - don't break the build for new pacts that have not yet passed verification. Work in progress pacts - run verification for the latest pact for any branch which is still pending, and which was not explicitly specified by the provider verification configuration. I was looking at using WIP to manage feature flag variations. But if WIP only runs for pending pacts, how do I make sure that a feature flag pact that previously passed verification will get verified in the future, when the provider changes?

Hi! Does anyone know where the documentation for the body of the POST request of the provider setup url parameter is? I get the following body:

{
  "consumer": "Consumer",
  "state": "User exists and has resources",
  "states": [
    "User exists and has resources"
  ],
  "params": {}
}

I wanted to ask if anybody has worked with Pact and Flutter applications as a consumers 🙂

https://docs.pact.io/implementation_guides/ruby/readme/ The link is broken

Happy Friday 👋 In case you missed it, lots happening over at Pactflow HQ. As a sneak preview, if you were ever wondering how to combine contract testing with OpenAPI, this might be for you! https://pact-foundation.slack.com/archives/CLS16AVEE/p1645163512468319

Sorry if this isn't the right place to pose the question. I'm really interested in contract testing & pact. I'm just trying to get an idea of how widespread the adoption is. I saw on pact.io there some big names listed like Atlassian, but can I be pointed to any other well-known microservice-heavy organizations that heavily invest in contract testing? Even if they don't use pact, but perhaps use contract testing to address the integration testing problem at large. Not that big names always matter, but I think demonstrated success can provide confidence. Part of this is me trying to 1) make sure this is the right path for my team, 2) convince my team/manager that we should go forward

Hello Pact Team, I really don't know where I can ask for the right channel? However, I try to run workshops which JS and Golang. I've found the same problem with Ruby. So I am not sure how to fix it. Golang: https://github.com/pact-foundation/pact-workshop-go

<class:CGIHandler>': incompatible character encodings: ASCII-8BIT and UTF-8 (Encoding::CompatibilityError)

JS: https://github.com/pact-foundation/pact-workshop-js Anyone please help me to fix this 🙂

Hello All 👋 I am still exploring Pact and I just wanted to share this little demo of "How to use the

--provider-state-header-name

option of the

pact-stub-server

in order to select one specific provider state in case multiple matching interactions are found" | https://github.com/patricekrakow/play-with-pact/blob/main/misc/select-provider-state.md Sometimes, as a consumer, you want the API to return a different response for the exact same API request depending on the provider state. By default, when the

pact-stub-server

received a request for which there are multiple matching interactions, it will just select the first one. However, you can specify the provider state you want via a custom HTTP header, I love it 🤩

QUESTION(S): If you would draw the "scope" of respectively "functional testing" (owned by the provider) and "contract testing" (owned by the consumers) as a Venn diagram, (a) would you fully include the "contract testing" circle/set within the "functional testing" circle/set, or (b) would you have a part of the "contract testing" circle/set not included within the "functional testing" circle/set? If you would go with option (b), what would be a representative example of a "contract test" not being as well a good "functional test"? I do have my own answers to these questions - being more "dynamic" than just replying (a) or (b) - but, I am wondering what are your thoughts... P.S. This question has been triggered by the great video "Best practices for writing consumer tests" with @Beth (pactflow.io/Pact Broker/pact-ruby) |

Hi All 👋 I am curious if somebody dealt with applying contract tests to libraries. I have a provider with quite complex API, and the team who develops this provider also ships the client library that hides the complexity of this interface. They still want to guard this interface with contract tests, which resulted into contracts between the provider and the library. The library of course is not deployable by itself, so they cannot apply can-i-deploy tool to it. Therefore, when consumers that integrate the library are deployed, there is no way to see if some contracts are broken or not. The alternative is of course to implement contracts between services ignoring the library, but then consumers will need to know the details about the API in between the library and the provider, which is currently nicely hidden from them. Any thoughts? 🙂

Shipping a client library and doing consumer driven contract testing sound like complete opposites to me

I am new to Pact Contract Testing. I am using Pact-go and I have a Struct with String[], I need to write a pact:example for this, but I am getting error "`struct field tag

json:"tags" pact:"example="Name::CustomerName","Status::Live""

not compatible with reflect.StructTag.Get: key:"value" pairs not separated by spaces`". JSON value is

"tags":["Name::CustomerName","Status::Live"]

Under Struct, this is what I have which is throwing error. `Tags []string `json:"tags" pact:"example="Name::CustomerName","Status::Live""`` can someone tell me the correct format of pact:example for string[]?

I am new to pact contract testing . When i try to build provider service i am facing below error . Could you please help .

Having embarked upon looking at consumer-driven contract testing against a GraphQL server, I've come to the point where I need to step back and ask folks here about the appropriate strategies for this compared to testing REST contracts. With a REST provider, contracts tend to be based on quite specific endpoints with focused responses, and (tricks with Accept headers and query parameters aside) there isn't a whole lot of flexibility in what the consumer can expect out of e.g. the response to a GET. This allows provider tests (state change handlers) to be less consumer-focused (ideally completely decoupled from a specific consumer). With GraphQL, the entry points to the graph that a particular consumer app uses may be relatively small in number to choose from, but the number of different navigation paths from that starting query grow exponentially as the graph becomes larger and more connected. So what should such contracts be about? It seems to me that at its simplest the contract could be verifying the schema-correctness of the provider query; schema-correctness is relatively simple to test in most GraphQL servers, but what about the details of the response matching, and how far down the GraphQL server stack should be mocked in the state change handler? Is this an appropriate use of pact? With the chances that any two consumer app's queries being alike very small, it feels like a full-stack state change handler that needs to provide the right returned data shape is going to either become extremely messy to maintain, or will need to do a lot of introspection and mock relatively high up the stack, or there will be effectively one state change handler per consumer contract. If anyone has any opinions or experience on the benefits of different approaches to GraphQL consumer-driven contract testing, I'd be very interested - TIA.

Hey Guys, I've come across this below question, can you please provide some insights? Bascially, per my understanding there are two ways to create/run pact tests.. 1. create and run the pact tests just like unit tests i.e mock all the input data as we do in traditional unit tests (no need to spin up the dependencies and no need to create the instance of application) 2. spin up the environment, run the instance of the application along with all the dependencies like database etc and then run the pact tests.. I understand that the major usp of pact is that it provides fast feedback and hence #1 should be relevant. However, I would like to hear your thoughts as well.

Hi 👋 I'm reusing a participant (my consumer) with a colleague who has created a provider. And I'm seeing two integrations in PactFlow. The error I would like to fix is below...

Computer says no ¯_(ツ)_/¯

There is no verified pact between version 2eaea58+1646755788 of pactflow-example-consumer and the version of pactflow-example-provider currently deployed to production (no such version exists)

But I don't want to verify the

pactflow-example-provider

I only want to verify the new integration

pactflow-example-provider-restassured

.

Hi all! I'm trying to find a good way to debug my tests in Intellij. Does anyone have a run configuration or any general tips of how to set this up? Thanks in advance!

Hello, One of our provider send a JSON like

{
  "level": 0,
}

But suddenly, they changed the

level

value to

2

which broke our consumer. Is this something we should verify with a contract test?

Hi, has anyone here experimented with PACT's messaging API? I'm looking at the state providers/handlers but I don't see much about their usage in the messaging API.

Hi guys, good morning 😎👋; I'm new to testing with PACT, is there any way to get the response of the calls to the APIs after the provider side verification was done? my code is as follows

describe("Validate pact of identity", () => {

    it("Validate pact of identity creation", () => {
        let opts = {
            providerBaseUrl: baseUrl.BASE_URL,
            changeOrigin: true,
            provider: "Create identity",
            logLevel: "DEBUG",
            pactUrls: [
                path.resolve(
                    process.cwd(),
                    `./__tests__/contract/pacts/${identity_data.nameConsumerPactFile}-${identity_data.nameProviderPactFile}.json`
                ),
            ],
            requestFilter: async (req, res, next) => {

               

                req.headers["authorization"] = "Bearer UQiQPSG-MtD3mNHG0JZT2mqfBh1",
                    next()
            },
            consumerVersionTags: ["QA"],
            providerVersionTags: ["QA"],
            publishVerificationResult: false,
            providerVersion: "1.0.0"
        }

        return new Verifier(opts).verifyProvider()
            .then((res) => {
                console.log('-------> here I need to get the response <-------', res);
            }).catch((res) => {
                console.log('Pact Verification FAIL!: Get identity ', res);
            });
    })

})