https://pact.io logo
Title
g

Giulio Giovannini

05/25/2023, 8:51 AM
Hi! I am testing the bi-directional contract testing and I have a problem with pactoflow not matching the resource url between the consumer and the provider. The consumer contract has a request to path
/mybaseurl/resource
while the provider Open API Spec yaml starts with a servers parameter like:
servers:
  - url: /mybaseurl
and then defines the resource as:
/resource
    post:
      ...
Pactflow can not match the paths as it disregards the servers parameter. The open Api Spec is autogenerated by Springboot so I can not change it that much. Is there a workaround for this?
y

Yousaf Nabi (pactflow.io)

05/25/2023, 9:20 AM
The open Api Spec is autogenerated by Springboot so I can not change it that much.
You can, that is the major selling point of using a machine readable specification
Is there a workaround for this?
I would assume as an initial pass, it would be to add the path on servers.url[0] into the front of each of your path entries
and Hello Giulio!
g

Giulio Giovannini

05/25/2023, 10:03 AM
Hi. Thanks for the info. So, you are saying to edit the AOS in order to add the basePath to each of the paths before publishing it to pactflow, correct?
y

Yousaf Nabi (pactflow.io)

05/25/2023, 10:11 AM
I believe based on what you've said about your consumers requests that should satisfy it. Worth a shot 🙂
g

Giulio Giovannini

05/25/2023, 11:13 AM
Yes, that will work and in my tests actually worked. But editing a OAS that was auto-generated to make it match the consumer contract looks a bit of a hack. Will do that for now. I will keep looking for a better solution.
y

Yousaf Nabi (pactflow.io)

05/25/2023, 11:39 AM
schema compliance is only going to get you so far, performing full pact provider verification will offer more guarantees
But editing a OAS that was auto-generated to make it match the consumer contract looks a bit of a hack.
You’d be surprised at the amount of auto-generated OAS’s that do need work to be usable/human readable
its also use cased based, you wouldn’t do it for every case, but if this case, you know it works, then its a valid solution, you don’t just completely modify the OAS to not reflect reality
I very rarely advocate for code generated OAS’s or if they are auto generated, to be ratified against a design first approach to an API (ie a hand crafted OAS based on actual expectations, rather than a result of the code)
ie how do you know the auto generated OAS completely reflects that of your code, and also completely reflects the requirements of your API in the first place
g

Giulio Giovannini

05/25/2023, 12:26 PM
For this last question, I have to trust the OAS generating engine. In theory it implements the same rules that are used to marshal the incoming JSON to the classes the HTTP body is mapped in. I haven't checked but I tend to trust that it will reproduce what is in the code.
m

Matt (pactflow.io / pact-js / pact-go)

05/25/2023, 10:25 PM
I’ve created https://github.com/pactflow/swagger-mock-validator/issues/28 to track this Giulio. There was an internal card for this already, but you can follow the progress above. As there is a relatively simple workaround it’s not at the top of the pile, and when there are multiple servers provided the rules for validation become a little more messy.