Jor van der Poel
08/06/2024, 12:38 PMbdct
.
Our current workflow is that the backend team designs their API's first, they then programmatically create an OAS out of that, the FE team then manually checks this file to develop their application, obviously, there is room for improvement here.
Since the BE team is not necessarily testing all these functions, we have decided for now to focus on the FE first. Because of this, we have uploaded the OAS to PactFlow using the provided Docker image, and are using this 'trick' to skip Provider verification:
--verification-results /app/report.txt \
--verification-results-content-type text/plain \
--verifier "Provider not actually verified, we will implement this after FE"
So at this point we have the Provider in Pact, as well as the FE contract, so we have an Integration.
My question then is, can we get this Integration verified with our current method (no BE tests)? In the documentation it is mentioned that:
Testing the provider API is your responsibility. PactFlow simply ensures the specification is compatible with any consumers
So based on that, we should be able to verify our integration right, or am I missing something?Matt (pactflow.io / pact-js / pact-go)
--verification-exit-code=0
otherwise the self-verification result will default to “failed”Matt (pactflow.io / pact-js / pact-go)
Since the BE team is not necessarily testing all these functions, we have decided for now to focus on the FE firstjust so we’re super clear, all the bi-directional check will do is to ensure the consumer pact contract is compatible with the OAS, it’s not doing other checks. So if you’re not confident the API described by the OAS is working, you should factor that into your process (e.g. I wouldn’t rely on
can-i-deploy
yet, because you might get a false sense of security).
But if the question is simply about getting all of the plumbing working, then that seems fine to me