Happy Friday everyone woo The August edition of the Pact Open Source Update is out now https://docs.pact.io/blog/2022/08/24/pact-open-source-update-august-2022 We are focusing on Pact-JS v3 and the people that made it happen, thank you so much and have an amazing weekend 😎!

How to test graphql ?

Which libraries is best?

Hi , I have an array in response . The structure of array elements is different from one another . Not able to write expected body match of consumer test and it is giving error " No best type found for implicitly typed array " : Following is the response [2:45 PM] "extension": [ { "url": "http://xyz.com/fhir/v1/StructureDefinition/schedulable", "valueBoolean": true }, { "url": "http://xyz.com/fhir/v1/StructureDefinition/serviceOrganization", "valueReference": { "reference": "Organization/Organization-Dept-1", "display": "myDepartment" } } ] [2:46 PM] How do i verify an array having different structure of elements

Hello, if my provider has 2 endpoints (/products and /statistic) and i have 2 consumers 1/*online-store* that uses the /products end point, 2/*analytic-service* that uses /statistic end point can both consumer pact tests have the same provider name? Would the pact files generated by the consumer tests get combined when uploaded to pact broker or one will replace the other?

Does anyone have experience performing can-i-deploy checks and recording deployments using Kubernetes / Helm? I wondering if it makes sense to use Helm hooks for these steps. Has anyone had success with that?

Regarding to the

pactbroker.providerBranch

or tag I still need some clarification. When I do this in Jenkins, what is the value I should assign to that variable?

GIT_BRANCH

or

GIT_MAIN_BRANCH.

From my understanding, the reason we are setting a value here because only that provider branch is eligible for pending pact feature. Is that right?

Hi, I'm facing the below issue while publishing the pact json :

Publishing 'ppe-service-bus-issue-compilation-ppe-service-ent-issue-compilation.json' ... FAILED! 409 Conflict - {"error":"Cannot change the content of the pact for ppe-service-bus-issue-compilation version 1.0.0 and provider ppe-service-ent-issue-compilation, as race conditions will cause unreliable results for can-i-deploy. Each pact must be published with a unique consumer version number. For more information see <https://docs.pact.io/go/versioning>"}

I'm not sure why it is failing and the same json file is getting verified when the run the provider from my local machine pointing to the json file. Any idea?

I have tried to invoke the endpoint that publishes the contract with a similar body mentioned below and got a response:

{
  "pacticipantName": "Foo",
  "pacticipantVersionNumber": "dc5eb529230038a4673b8c971395bd2922d8b240",
  "branch": "main",
  "tags": [
    "main"
  ],
  "buildUrl": "<https://ci/builds/1234>",
  "contracts": [
    {
      "consumerName": "Foo",
      "providerName": "Bar",
      "specification": "pact",
      "contentType": "application/json",
      "content": "<base64 encoded JSON pact>"
    }
  ]
}

Response:

{
  "notices": [
    {
      "type": "error",
      "text": "Cannot change the content of the pact for ppe-service-ent-issue-compilation version 1.0.0 and provider ppe-service-ent-issue-compilation, as race conditions will cause unreliable results for can-i-deploy. Each pact must be published with a unique consumer version number. For more information see <https://docs.pact.io/go/versioning>"
    },
    {
      "type": "info",
      "text": ""
    }
  ],
  "errors": {
    "contracts": [
      "Cannot change the content of the pact for ppe-service-ent-issue-compilation version 1.0.0 and provider ppe-service-ent-issue-compilation, as race conditions will cause unreliable results for can-i-deploy. Each pact must be published with a unique consumer version number. For more information see <https://docs.pact.io/go/versioning>"
    ]
  }
}

I dont see any difference in the content that is causing this issue

Hi, Can we use pact for integration tests with mocking rather using mock-server ?

⬆️ Level up your testing game with Full Stack Testing Academy Are you hunting for contract testing training materials for you and your team? Our friend @Bartosz Pietrucha – the founder of Fullstack Testing Academy – covers this in his course, including launching a new Pactflow module. The course starts on October 6th, 2022. Our Developer 🥑 @Yousaf Nabi (pactflow.io) has personally completed the course and has given it the 👍. It covers all you need to know about full-stack web application testing and automation. We think it will be helpful for many teams in improving their test quality, knowing how and when to employ test automation at what level, and using tools in their appropriate context. From unit, integration, E2E tests, and automation to CI/CD and contract testing, everything is in one place. @Bartosz Pietrucha is generously providing our community with a €50 discount. Use the code

PACT_FLOW_50

to secure your spot. Sign up 👉 <https://pactflow.us4.list-manage.com/track/click?u=d975bc32fd84ad3580ed4777e&id=1581d47252&e=f3a6913421 |here>. The course will teach you: • the good practices of unit, integration, and e2e testing and learn how to implement them in front-end and back-end • How to test the architecture from different perspectives like dependencies and abstraction layers • The importance of setting up different quality gates in the project securing its long-term success • How to establish an automation mindset to free your time to do the “real work” and monitor quality metrics provided by different tools The course is delivered via 1-2 hours of dense video content, with assignments after each module to put into practice what you learned. In includes lifetime access to on-demand video lessons, as well as ten weeks of support on Slack and via Zoom. If you have any questions, I’m sure @Bartosz Pietrucha will be happy to to field them.

Hello! I have three questions about the global Pact conception. 1. Please, tell me, should I separate pact files demands on provider features? For example, I have an API for the Task Manager application and implemented API by feature architecture on the C# language. Such as TaskCrud (CRUD operations on tasks), TaskFilter (filtering tasks) etc. And SPA React application, where I write contact tests. So my question is, should I have a single pact file (e.g.

task-api-consumer-task-api-provider.json

) for checking responses to all features from the provider side or better split generating pact files depending on provider features (e.g.

task-api-consumer-task-api-provider-crud.json

and

task-api-consumer-task-api-provider-filter.json

) and after that writing two verification test methods on the provider side for each coming pact files? 2. Where should I save the pact file path? Is reading from a configuration file (such as launchSettings.json) for a test project better than C# constant? 3. If a consumer has many providers, which algorithm is better to use if I need to publish one pact file to a specific provider? Depend on the pact file prefix, or save the pact file in a particular folder during generation on the consumer side on passing tests? Thanks, Maksym

👋 Hi everyone! I’m quite interested in contract test. Our system has two parts: one is on cloud, the other is on edge. They communicate via MQTT (over websocket). How can this be contract tested? Will pact help in this case?

Hello! I feel a bit confused about using provider states. Even after reading documentation, seeing examples of test applications on the web and trying to find related answers about that - even after that, it is tough to consolidate naming and describe a little algorithm of his naming. So, as I can see, if we are mocking the repository layer (or even the business service layer that is directly referenced to the repository layer) - we should set a human-readable provider state. For example, for Task Manager API and test

GET

and

POST

methods, we should name the provider states as

Task with existing ID is available

and

Task with the correct body is created

. But, how should we call the provider state of checking unauthorized scenarios or bad requests (with invalid request body)? And which name of the provider state is better in the point of view of Pact best practices, the first one or

post-task-success

and

get-task-success

?

Hello! I wanted some clarification because I'm a bit confused. I have read in the doc that Pact supports several languages, but I just want to make sure that I can write the provider-side verification in goLang and use typescript for the consumer-side.

Hi there! Could someone explain me what's the point of using 'Environment' in pactflow? I thought it's replacement for tags but seems like I'm wrong

Getting the below error while running pact test in the consumer side... i might be doing something really stupid but just can't figure out what...

'use strict'

process.env.REACT_APP_ENGINE_SERVICE_URL = '<http://localhost:8992>'

import { expect } from 'chai'
import path from 'path'
import { Pact } from '@pact-foundation/pact'
import { fetchACEFields } from '../api/index'

describe('fetch ACE fields', () => {
  const port = 8992
  const objectType = 'dummy'
  const provider = new Pact({
    port: port,
    log: path.resolve(process.cwd(), 'logs', 'mockserver-integration.log'),
    dir: path.resolve(process.cwd(), 'pacts'),
    spec: 2,
    consumer: 'webapp',
    provider: 'engine-service',
    pactfileWriteMode: 'merge',
  })

  const expectedBody = { status: true, data: [{ fullName: 'dummy' }] }

  before(() => provider.setup())

  after(() => provider.finalize())

  afterEach(() => provider.verify())

  describe('request to fetch fields', () => {
    before(done => {
      const interaction = {
        state: 'fetch ace fields',
        uponReceiving: 'a request to get all ace fields',
        withRequest: {
          method: 'GET' as const,
          path: `/ace-fields?object_type=${objectType}`,
          headers: {
            Accept: 'application/json',
          },
        },
        willRespondWith: {
          status: 200,
          headers: {
            'Content-Type': 'application/json',
          },
          body: expectedBody,
        },
      }
      provider.addInteraction(interaction).then(() => {
        done()
      })
    })

    it('verify it returns the correct response', async () => {
      const res = await fetchACEFields(objectType)
      expect(res).equal(expectedBody)
    })
  })
})

Error: 
   ReferenceError: navigator is not defined
    at Object.<anonymous> (/Users/snehasingh/Documents/webapp/node_modules/flags/node_modules/supports-color/browser.js:3:58)
    at Module._compile (internal/modules/cjs/loader.js:1068:30)
    at Module._extensions..js (internal/modules/cjs/loader.js:1097:10)
    at Object.require.extensions.<computed> [as .js] (/Users/snehasingh/Documents/webapp/node_modules/ts-node/src/index.ts:1445:43)

Hi team I try to do timestamp check in LambdaDSL，is there a proper way to do accurate timestamp check in LambdaDSL？For now I only do a looser type check：

.object("updatedAt", updatedAt ->
                                updatedAt
                                        .integerType("epochSeconds",1661307606)

Hi all! 👋 Next week I’ll be speaking at API Days in Melbourne, on the challenges of testing modern, multi-protocol microservices at scale. The talk is titled: “Schemas are not contracts! Why contract testing matters in the age of gRPC, Kafka and GraphQL” I have 10 free in-person tickets to give away for the conference (worth about $800 AUD). If you are keen in attending, use the promo code IKNOWMATTFELLOWS , register here (and drop me a DM). No strings attached, please feel free to share to anyone who might benefit from a great conference. You can also register for free online access Hope to see you there 🙂

Any idea what is causing this:

'use strict'

process.env.REACT_APP_ENGINE_SERVICE_URL = '<http://localhost:8992>'

import path from 'path'
import { Pact } from '@pact-foundation/pact'
import { fetchACEFields } from '../api/index'

const port = 8992
const objectType = 'dummy'

const provider = new Pact({
  port: port,
  log: path.resolve(process.cwd(), 'logs', 'mockserver-integration.log'),
  dir: path.resolve(process.cwd(), 'pacts'),
  spec: 2,
  consumer: 'webapp',
  provider: 'engine-service',
  pactfileWriteMode: 'merge',
})

describe('fetch ACE fields', () => {

  const expectedBody = { status: true, data: [{ fullName: 'dummy' }] }

  beforeAll(async () => {
    await provider.setup();
  });


  describe('request to fetch ACE fields', () => {

    beforeAll(async () => {
      await provider.addInteraction({
        state: 'fetch ace fields',
        uponReceiving: 'a request to get all ace fields',
        withRequest: {
          method: 'GET',
          path: `/ace-fields?object_type=${objectType}`,
          headers: {
            Accept: 'application/json',
          },
        },
        willRespondWith: {
          status: 200,
          headers: {
            'Content-Type': 'application/json',
          },
          body: expectedBody,
        },
      });
    });
    test('verify it returns the correct response', async () => {
      const res = await fetchACEFields(objectType)
      expect(res).toBe(expectedBody)
    })
  })
})

👋 Hey all, hope you are doing well. I’ve just created a new Slack channel called #C041GBL8M9T where you can post, or see links to Pact/Pactflow and Contract testing related posts. If you have any posts you want to share, feel free to pop them in. If you post about contract testing, let me know. I think I would like to build up an RSS feed for contract testing related posts, similar to MinistryOfTesting’s testing feed Also thank you to @Anja Gruss for the first post to go live in #C041GBL8M9T, why not hope over and check it out

Hey community, thanks in advance for the support! Let’s assume a consumer application triggers a post call to a provider. Within the request of that call comes a request body in a json format. I wonder if the consumer should structure that request body with matchers just like he does with response body, or should he put a json-object for any reason? My suggestion is to use matcher for request body just like with the response body, but I’m not what’s best practice here. Thanks!

Hello, i wanna use the pactfoundation/pact-cli docker image to run my bash script to record deployment to pact broker as the last step of my CI/CD pipeline. Since we have quite a number of services deployed, my bash script need to loop over the deployed services and run "pact-broker record-deployment" for each. However, i soon realized that this docker image does not have bash and when i build a custom image from this image with bash installed, i got "NoMethodError - undefined method `request_uri' for #<URI::Generic ?>" when calling pact-broker. I suspect the ruby env is missing something when running from bash. Do you have a docker image built with bash instead of sh? if not, how do i fix this undefined method error?

We are starting to explore gRPC as a replacement of HTTP REST in my company, some developers argues that contract testing isn't necessary anymore. What value does pact bring in such situation?

Guys, I created a repository demonstrating how it should be the implementation of webhook, pipeline and contract tests of Provider and Consumer applications in order to achieve what is considered Pact's Nirvana. The diagram in README.md can help group members understand the entire architecture of contract testing. It is in Brazilian Portuguese, but google translator can help. Depending on the demand I translate. https://github.com/PauloGoncalvesBH/nirvana-teste-de-contrato

People, I created a repository demonstrating how it should be the implementation of webhook, pipeline and contract tests of Provider and Consumer applications in order to achieve what is considered Pact's Nirvana. The diagram in README.md can help group members understand the entire architecture of contract testing. https://github.com/PauloGoncalvesBH/contract-test-nirvana

Where is the doc for matchers formats located? I think I can't find it. I'm looking for something like this: • v2: `"name": { "contents": "rover", "json_class": "Pact::SomethingLike" }, "type": { "data": { "generate": "bulldog", "matcher": { "json_class": "Regexp", "o": 0, "s": "bulldog|sheepdog" } }`https://docs.pact.io/slack/pact-message-ruby.html#1522380995.000036 • v3: `{ value: 123, 'pactmatchertype': 'type'}`https://github.com/pact-foundation/pact-js/blob/master/src/dsl/matchers.ts I think the

matchers

in https://github.com/pact-foundation/pact-specification/tree/version-2 and https://github.com/pact-foundation/pact-specification/tree/version-3 is something else different, not related, right? I can't find it here too https://docs.pact.io/getting_started/matching

Hi, I am trying to implement Pact as contract testing for our company. Currently I do not understand following: • I have got working test on consumer service and verify on provider service • when consumer service is built and

can-i-deploy

passes new contract is published to pact broker (this is in build pipeline) • this publishes contract e.g.

consumer 1.0 & provider 1.0

◦ when I deploy

consumer 1.1

this will publish contract

consumer 1.1 & provider 1.0

◦ when I deploy

consumer 1.2

this will publish contract

consumer 1.2 & provider 1.0

now my question is if I deploy

provider 1.1

how do I publish new contract between consumer and provider? I guess in this case if we follow the above example if

provider 1.1

is deployed then contract between

consumer 1.2 & provider 1.1

should be published? how do I publish this new contract new consumer builds? or am I missing something?

Hi, is anyone using Pact to mock out and verify the responses from a document store like ElasticSearch? I have a use case where I’d like to avoid needing to have a running instance of ES when running automated tests locally, but still have the opportunity to verify the expectations are valid, and it seems like Pact might be good for this. Curious to know if this would be feasible and if anyone else has done this before?

Hi all, I am looking into implementing contract testing within a new project. The thing is: we are developing our api's using a contract first approach. And the contracts themselves are part of a separate git repo. I'm looking for any documentation or examples of such projects so that we can determine how we could implement contract testing on this project. If anyone has any tips, please let me know 🙂