https://pact.io logo
Join Slack
Powered by
Hi! I am testing the bi-directional contract testi...
# pactflow
g
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:
Copy code
servers:
  - url: /mybaseurl
and then defines the resource as:
Copy code
/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?
đź‘‹ 1
y
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
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
I believe based on what you've said about your consumers requests that should satisfy it. Worth a shot 🙂
g
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
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
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
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.
Hi @Giulio Giovannini we have been looking into this change. It gets quite complicated quickly. For example, it’s possible to have multiple servers, with conflicting base URLs:
Copy code
servers:
  - url: <https://hostname/v1>
servers:
  - url: <https://hostname/api/v1>
We would need a way to resolve this reliably without making it confusing. You can also have not just ambiguity, but straight up conflicts. e.g. it’s also possible to have conflicts at the 
path
level, like so:
Copy code
paths:
  '/fruits/apple'
    servers:
      - url: <https://hostname>
  '/apple'
    servers:
      - url: <https://hostname/fruits>
These two would theoretically be the same, as far as the “resolved” path would be.
How would you expect the tool to behave in those cases?
Open in Slack
PreviousNext
Powered by