Hi, question about bi directional. Team adoption ...
# pactflow
d
Hi, question about bi directional. Team adoption and the possibility of non devs contributing is very appealing to us. However, to validate the spec, you still need to run the provider api, then test against it (ie with Postman). In this case, they would be integration tests unless someone (devs) mocked the responses. Is that correct? Is there another way?
b
What do you mean when you say ‘validate the spec’? The whole idea of BDCT (and contract testing in general) is to reduce relying on integration tests. From the consumer perspective, you’ll publish a consumer contract (generated using Pact or derived from other tests). From the provider perspective, all you need to do is publish the OpenAPI spec. PactFlow will then check if there are any potential integration issues. No further mocking of the provider needed. Unless you mean you need that to generate the consumer spec? You could do that using the Pact mock server (when you use Pact) or, if they exist already, tests against an existing mock provider (WireMock, for example). No need to build a mock or use an actual provider instance just for BDCT.
d
I may not have understood it properly. I'm just going off what I saw in one of Matts demo videos for the provider, where it seemed that you should validate the api with tests, then convert the tests into a spec.
b
Ah, I think you're referring to the additional test evidence that the provider is required to upload to PactFlow when the spec is published. Ideally, that is indeed a test log generated on the provider side when they build their service, and the OpenAPI spec is only generated after those tests pass. But that does require some way to communicate with the provider and getting them to work in this way. The good news is: Pactflow only requires some content to be published alongside the spec itself, but it doesn't care much (or at all) what that content actually is. At least not at the moment. It could be test results. It could be an inspirational quote. It could be a base64 encoded version of today's XKCD. You get my point 🙂
m
It could be an inspirational quote
😆
Yep, thanks Bas. The point is - PactFlow cares that you have confidence in the use of
can-i-deploy
. For you to have confidence in relying on that, we need to make sure your OAS is a valid representation of your provider. For you to have that confidence, you need to have tested that somehow. We’re not opinionated in how you do that, but the point is you should do it. If you don’t, that’s also fine, but just be aware that the confidence you get is proportional to the confidence you have in the OAS
d
I had a similar question actually, we autogenerate our swagger docs so we have pretty high confidence that they are correct. It looks like the CLI requires some kind of verification regardless including passing a file with the verification results. Is there way through the CLI to indicate we have verified without passing all 4 flags?
Copy code
--verification-success --verification-results-content-type=text/plain --verifier=oas --verification-results=./verified.txt
y
negative, they are mandatory and displayed in the UI. I tend to upload the OAS for the verification results to avoid generating another file, in your case. (although the output of any of your provider tests would potentially provide confidence of the functional testing conducted for consuming teams)
d
Cool, thanks for your response, we are actually uploading the OAS file as well!