https://pact.io logo
Join Slack
Powered by
Sir basically its quite a complicated query. I hav...
# pact-js
s
Sir basically its quite a complicated query. I have a GET request which responds back with a UUID and a string. When I create a consumer test I create with an ID say e5173b29-d597-434e-872b-71db298bbe8f. Now when I run my provider side of tests it expects the same UUID for the test to pass. I am creating a new stack and I do not have the UUID in the DB yet. How do I circumvent this situation
y
use provider states and matchers, matchers so you expect a key that looks like a uuid not the actual fixed uuid
☝️ 1
the provider state can be read in the provider test to setup the required data
☝️ 1
in which it would return a uuid, which could be validated to ensure if matches a valid uuid. i assume the actual specific id isn’t of importance
s
the UUID goes in the path of the url something like base_url/e5173b29-d597-434e-872b-71db298bbe8f
sorry @Yousaf Nabi (pactflow.io) I have spent 3 days already trying to get around this
y
it matches your use case
The 
fromProviderState
matching function allows values to be generated based on values returned from the provider state callbacks. This should be used for the cases were database entries have auto-generated values and these values need to be used in the URLs or query parameters.
m
What Yousaf said. Most people don’t need 
fromProviderState
, provider states themselves should work for 99% of people
Do you have control over your provider? i.e. do you have access to the code or are you testing against a fixed environment?
s
Yes I have control
I am still struggling when I look at the logs it says
[134545.092] DEBUG (20768): pact@11.0.2: Proxying GET: /anyguuuid
That what is in the pact.json
and no matter what I do when I run the state handler it runs based on /anyguuuid value
Copy code
{
  "status": 200,
  "headers": {
    "Content-Type": "application/json"
  },
  "body": {
    "details": "some string",
    "id": "4f2fa219-c805-4781-937c-bf3296e93cc4"
  }
}
*{*"method": "GET", "path": "/anyguuuid", "headers": *{*"Content-Type": "application/json" } }
This is my pact
I do not want it to use the /anyguuuid in the path
I want to substitute at runtime for a newly created id
Any word for me @Yousaf Nabi (pactflow.io) @Matt (pactflow.io / pact-js / pact-go)
y
read the docs
and don’t tag me
You need to uses matchers not an explicit value in your path
s
I am using mathers
const dynamicPath = term({ matcher: '.*', generate: '/anyguuuid' });
path: dynamicPath,
y
well if that if your pact above you have shown you don’t have matchers encoded in your contract
s
Yes its not
y
If you want help, please provide a reproducible example
and note that this is completely on volunteer time
s
I know
But I spent ages on this so got a bit desparate
y
I get that my friend, I’d love to be able to help you, do you think you could make a simple example in a public repo?
s
Copy code
{
  "consumer": {
    "name": "syncconnectors-bullhorn-get"
  },
  "interactions": [
    {
      "description": "A Request for obtaining credentials",
      "providerState": "I get credentials",
      "request": {
        "headers": {
          "Content-Type": "application/json"
        },
        "matchingRules": {
          "$.path": {
            "match": "regex",
            "regex": ".*"
          }
        },
        "method": "GET",
        "path": "/anyguuuid"
      },
      "response": {
        "body": {
          "details": "some string",
          "id": "4f2fa219-c805-4781-937c-bf3296e93cc4"
        },
        "headers": {
          "Content-Type": "application/json"
        },
        "matchingRules": {
          "$.body.details": {
            "match": "regex",
            "regex": ".*"
          },
          "$.body.id": {
            "match": "regex",
            "regex": ".*"
          }
        },
        "status": 200
      }
    }
  ],
  "metadata": {
    "pact-js": {
      "version": "11.0.2"
    },
    "pactRust": {
      "ffi": "0.4.0",
      "models": "1.0.4"
    },
    "pactSpecification": {
      "version": "2.0.0"
    }
  },
  "provider": {
    "name": "secret-store-get"
  }
}
This is my json
y
ok ty, so you are using the latest pact, but the v2 interface on the consumer side.
which matchers are you using v2 or v3?
s
V2
y
okay I’ll try and make a simple reproducible from here and update the package.json to match the latest version https://github.com/YOU54F/pact-matchers/blob/main/pact-js-v3-v10/matchers.v2.pact.test.js
can you share your provider side test
Just to circle back on this, we were able to resolve this for Sachin. Consumer side https://github.com/YOU54F/pact-matchers/blob/main/pact-js-v3-v10/path.v2.pact.test.js Provider side https://github.com/YOU54F/pact-matchers/blob/main/pact-js-v3-v10/path.provider.pact.test.js Utilising a combination of consumer side matchers and provider state, provider side state handlers, and request filters. There may be a more elegant solution but for now that has got across the roadblock encountered
👍 1
Open in Slack
PreviousNext
Powered by