https://pact.io logo
Join Slack
Powered by
Hi pactflow channel. With bi-directional contract...
# pactflow
r
Hi pactflow channel. With bi-directional contract testing, is it possible to define the request path for the consumer contract in a case insensitive way OR to configure the pactflow broker to use a case insensitive compare between the consumer contract path and the open api schema path? Our providers are primarily .net apps which use case insensitive routing out of the box and our open api schema specs are generated from the code using swashbuckle which outputs the swagger.json spec using pascal cased paths for the operations. This is causing pact verification failures due to case differences in the paths that don't matter for our apis.
y
r
I'm specifically asking about the request paths only, not the request body. The below paths are all valid to our provider.
Copy code
GET <https://something.contoso.com/api/v1/something/{somethingId}>

GET <https://something.contoso.com/api/v1/Something/{somethingId}>

GET
<https://something.contoso.com/api/v1/SOMETHING/{somethingId}>

GET
<https://something.contoso.com/api/v1/SomeThing/{somethingId}>
Specifying that the operation paths are case insensitive is not something that can be done at the open api schema level. Both of these are valid and will work for our api.
Copy code
// Consumer A test case
pactProvider
  .given('some case')
  .uponReceiving('request description')
  .withRequest({
    method: 'GET',
    path: `/something/1`,
    headers: { ... expected request headers ... }
  })

// Consumer B test case
pactProvider
  .given('some case')
  .uponReceiving('request description')
  .withRequest({
    method: 'GET',
    path: `/Something/1`,
    headers: { ... expected request headers ... }
  })
But the pactflow comparison of the pact .json and the open api schema currently says they're incompatible when the open api schema case and the pact .json case don't match
m
Unfortunately OAS is case sensitive and we interpret the OAS with that same case sensitivity
One approach if you can’t get consumers to be consistent, could be to post-process any pact files to downcase the paths (or the reverse, as the case may be).
If they are consistent, the simplest thing to do is update the OAS to be consistent with the consumers.
r
Thanks Matt. So far my POC test cases have found consumers which are not consistent. Not sure how prevalent those inconsistencies are. For context: I've doing the POC work in order to build a detailed picture of what would be required to adopt Pactflow bi-directional testing. The POC details are so I can attempt to sell the business and fellow engineers on adoption. I could recommend we change the consumers to require consistency. But there's a bit of drawback to that recommendation; more required changes needed for the tools to work becomes a harder sell for internal buy-in. I'm trying to minimize any such required changes, even just small stuff like case changes in paths.
I appreciate the suggestion to post process the files. I could probably provide a cross-cutting script for this which each team could utilize to bypass the need for more changes.
👍 1
Would SmartBear/pactflow team consider adding a feature to allow opt-in behavior for pactflow users to make just the paths comparison case-insensitive? I understand the need to be selective in regards to feature support. I would make the case that this is a fairly standard use case that could warrant opt-in support. Many major APIs follow the practice of url paths being canonically lower-case and case insensitive (e.g. StackOverflow apis). And as I mentioned this is the default behavior provided out-of-the-box for .NET apis. https://learn.microsoft.com/en-us/aspnet/core/fundamentals/routing?view=aspnetcore-7.0#route-templates
m
It certainly seems more common in the .NET ecosystem (where file systems are case insensitive by default), and not the case in linux based systems, which are correct 😆
But trolling aside, I’ll pop a note as a feature request.
It wouldn’t be hard to support at the comparison level, but exposing that toggle to users is currently not something we can easily do - so likely it would be an all or nothing change, and the consequences of such a change would require consideration
r
where file systems are case insensitive by default)
Don't know what you mean, .NET is cross platform.😝
but exposing that toggle to users is currently not something we can easily do
Just out of curiosity, what's the limiting factor? Lack of support for account level configuration at the pactflow implementation of the broker?
currently not something we can easily do - so likely it would be an all or nothing change, and the consequences of such a change would require consideration
Definitely would NOT make sense as an all or nothing change. Treating an api that does use case sensitive request paths as though it were case insensitive would definitely be the worse of the two options. If opt in isn't possible at this time then it only really makes sense as a feature request for some (hopeful) future point when opt-in is possible.
24 Views
Open in Slack
PreviousNext
Powered by