I'd like to be able to utilise "like" and "eachLike" Matchers

[stevenpollack]

Checklist

Before making a feature request, I have:

• Searched the issues to check that this feature hasn't been requested before
• Checked the documentation to see if it is possible to do what I want already

Feature description

Maybe the verifyTest method can take options like responseBody (and requestBody), and these would contain mock data would passed along to like or eachLike. E.g.

const mockResponse = {
  authorEmail: "[email protected]",
  componentType: ComponentType.SSA,
  description: "Description of the component",
  id: -999,
}

const interaction = new ApolloGraphQLInteraction()
  .uponReceiving('a query')
// ... you get the idea ...
  .willRespondWith({
    status: 200,
    body: like(mockResponse)
  }); 

So if I did something like

describe('some component', () => { 
  afterAll(async () => {
    await pactMswAdapter.writeToFile();
    pactMswAdapter.clear();
  });
  test('some specific query', () => {
    // go through the AAAs
    pactMswAdaptor.verifyTest({responseBody: like(mockResponse)});
  });
})

The resulting pact .json files could have appropriately rendered matchingRules properties. For instance, a response property of a graphql interaction might look like:

"response": {
  "body": {
    "data": {
      "deleteComponent": {
        "authorEmail": "[email protected]",
        "componentType": "ssa",
        "description": "Description of the component",
        "id": -999,
      }
    }
  },
  "headers": {
    "Content-Type": "application/json"
  },
  "matchingRules": {
    "$.body.data.deleteComponent.authorEmail": {
      "match": "type"
    },
    "$.body.data.deleteComponent.componentType": {
      "match": "regex",
      "regex": "null|ssa|cs"
    },
    "$.body.data.deleteComponent.description": {
      "match": "type"
    },
    "$.body.data.deleteComponent.id": {
      "match": "type"
    },
  },
  "status": 200
}

Use case

This is a very sensible thing to have when you're only interested in the shape of a response and not the exact values. For example, a service handling basic user information like

{
  name: string,
  age: number,
  email: string,
  country: string,
}

might not care about the exact age or country of the test data, so long as they are numbers and strings. Making our test data flexible allows for (cosmetic) data refactoring without worry about can-i-deploy freaking out.

Conversely, the adapter loses much of its potential utility if it creates pacts that are rigid in their assertions. Teams that require the use of like and eachLike (for example) won't be inclined to use this adapter because they'll have to manually define interactions a la pact-js.

[YOU54F]

I originally designed this tool to work with bi-directional contract testing whereby schema matching is done against the OAS from the pact example response and matchers are not required or used

https://docs.pactflow.io/docs/bi-directional-contract-testing/tools/msw

I would consider enhancements to the tool in order to support matchers, but I am unlikely to deliver it myself

[braydend]

@stevenpollack have you made an attempt to add the matching functionality?
I'm also quite keen for this functionality. Happy to help get this over the line

[stevenpollack]

Honestly, this got lost in the shuffle for me, when my team realised that it wouldn't be a fast fix. I think we ended up relying more on the `graphql-codegen`'s type creation to give us a similar sense of safety ...

…

On Fri, 16 Aug 2024, 9:54 am braydend, < ***@***.***> wrote: @stevenpollack have you made an attempt to add the matching functionality? I'm also quite keen for this functionality. Happy to help get this over the line —Reply to this email directly, view it on Gi *DuckDuckGo* removed one tracker. More <https://duckduckgo.com/-hGysyZFupsqvAi0nzhKiHW7Lo9F3OqfyEDCwOsPxtAM8Prs4UDWHAYxLA3OZ5fovFQs-LCWFCP1CxUypYC1ZArLU6CqUon13Ozczs-bEaIFtoMcKTjeRgWKmZyaZ2odknCFNz4SapbAJEQNF3TFWdxHk2dF1nvvzXMwD2LS1OUIO2IMC_E0NMmsXuoAFVObp53u-O0nfMp_pHlUlUw-V1jMgOVLb8RheesdC8KmrAp-utrl_SltK9n6gtC8YANTVCDbsj6WrCtfvZF3r6DXpD-PQw0VEGfqC2duBcTlranstW4sOCBwDUI8lAeF7LC8RCAXG4MZZjV5psC9VQoeMenAA8oCNLQskzAZygn37kFSctNEleqCojyDhLupS1qTRkahGW8hRTQj4LPINJ_L-4aFc3nyEpSygked-Z1I5e7r7DMh8KR3Nzx3Z1VcO6bvo8wuXkL0hHaty2o1hio9Ik60DeD3yNrhJWtNdkEIrQdq-7WQzbvJ0IYH1wFpD-_StIUliW7xg_5mCwqmnxVYmrkEIqYw06> Deactivate <https://duckduckgo.com/> @stevenpollack <https://github.com/stevenpollack> have you made an attempt to add the matching functionality? I'm also quite keen for this functionality. Happy to help get this over the line — Reply to this email directly, view it on GitHub <#191 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAT4RA2KTURNJDEB3NLYM53ZRU5THAVCNFSM6AAAAABD55JXL2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEOJSGQ3TGOBUHA> . You are receiving this because you were mentioned.Message ID: ***@***.***>