Hi Team I am interested in the bi-directional tes...
# pact-broker
m
Hi Team I am interested in the bi-directional testing. However am confused about the verification-results. It appears that they are needed alongside the openapi specs, however it isn't clear what format (if any) they need to be in?
👋 1
b
As far as I know they can literally be anything, but most commonly they’ll include provider-side test results as additional proof of due diligence. They won’t contain contract verification results as those are generated by Pactflow after the contract is published. I’ll admit the name is a tad confusing :)
👍 1
I’m still using the example I’ve given here: https://www.ontestautomation.com/an-introduction-to-contract-testing-part-6-bi-directional-contracts/ and so far Pactflow has never complained.
m
ah ok thanks. One more question. Versioning? say if we had an API which was versioned on the route? such as
v1/
and
v2/
would that be separate contracts or would you be able to have two versions of the same contract in prod?
b
A contract is connected to a version of an API. That could be anything from a major version like your example to a specific commit in a code base and anything in between.
m
I’ll admit the name is a tad confusing 🙂
Yeah, it is. We have an open ticket to try and improve the nomenclature around this. I’m sorry everyone!
One more question. Versioning? say if we had an API which was versioned on the route? such as
v1/
and
v2/
would that be separate contracts or would you be able to have two versions of the same contract in prod?
You can have them as separate applications if they are. If they are deployed together as a single unit (that serves two prefixes) then it should be a single provider contract (obviously each consumer would each have a single consumer contract)
m
thanks for clearing that up guys