Hi all, I need to build contract tests for a micr...
# pactflow-ama
n
Hi all, I need to build contract tests for a microservice based system, where some of the microservices interact with external APIs both as consumers and providers. For the interactions between "internal" microservices I am using classical Pact, but for the interactions with external APIs I am planning to use the new bidirectional contract testing approach as the documentation suggests it is better suited. I was wondering if anyone else has ever attempted this mixed use of Pact and bidirectional contract testing , or whether you think it is better to stick with one.
m
You can definitely use them together. In fact, you can even have regular and BDCT contracts on the same integration point. It’s worth noting that you’ll have decreased confidence for 3rd party providers - you’ll simply need to assume they actually implement the API. Depending on the situation, that assumption might be invalid and it may also not matter. e.g.. would you not deploy a consumer if the provider implementation in a particular environment changed in a backwards incompatible way (that is, it wasn’t compatible with the OAS you had)? In that case, likely your production system is broken in some form anyway, and now you can’t deploy a workaround. The scenario I’m thinking of are 3rd parties, where there are no test environments and then a signoff from you (the partner) is required, so all you can go off is a single environment (essentially prod).
n
Most of our partners do publish OAS specs (afaik they have never been inaccurate) which we use together with their API docs to create mocks of their API's. My thinking is that we can use their OAS specs for when the external API is a provider and we can assemble a consumer contract from our mock services following the example in the docs ( https://docs.pactflow.io/docs/bi-directional-contract-testing/contracts/pact#converting-mocks-into-a-pact-compatible-format) for when the external API is a consumer.
Am I missing anything ?
In principle our partners should alert us when they plan doing changes to their API if they break backwards compatibility and we should either have access to new specs or be able to create new ones.
So in principle we should not be faced with a situation like you described.
I think we should be able to verify wether our consumers are compatible with the new OAS in a test env.