I just finished reviewing and found Bi-Directional Contract Testing quite interesting! One question (maybe two dimensional) came to mind. Within a new micro-service architecture, which approach would you recommend, traditional pact or bi-directional pacts? An extra dimension to this is an internal consumer service with an external provider service. I would imagine the pact approach is quite useful for all of our internal services where we are building new apis. However, one of the bullet points on the slide Why and when would I use this? mentions Legacy systems that can't be unit tested. I automatically related this in our product's context as external systems that can't be unit tested. So what approach would you recommend for interactions of a consumer service with an external provider service from outside my organization? I could see leveraging a postman collections as a way to document the provider interactions and treating this external system as a legacy provider

Hey up Hazem, is your external system, that from another company. Do they provide a sandbox environment or would you be leveraging these against the live services. I would love to live in a world where public facing or private api’s but available to many consumers are coupled with a great developer experience. A portal you can go to for integrations, test accounts, a sandbox environment whereby you can be alerted to impending changes. Well documented services with something like OpenAPI, or in the case of event based services AsyncAPI. Would love to hear more about your use case. I can see the generation of an OpenAPI spec off the back of a tested Postman collection being useful, as shown in one of our demos, as that subset of the OpenAPI that you have tested, is a rich guarantee, rather than taking the full OpenAPI spec and utilising the existing OAS testing tools, which all have, to some degree limitations, and may not give you complete picture of confidence. Especially when coupled with a system that can only test from the outside in.

Yes, external in this case is outside our company. There is a sandbox.

However, one of the bullet points on the slide Why and when would I use this? mentions Legacy systems that can’t be unit tested. I automatically related this in our product’s context as external systems that can’t be unit tested.

yep, it’s probably a separate bullet point but you can definitely try this

Yeah, that last part their of most up-to-date seems ideal. Thanks for the input, 🙇🏽

Hi Pactflow team @Matt (pactflow.io / pact-js / pact-go) @Yousaf Nabi (pactflow.io), I also have question about bi-direction. The example it looks like it is setting up intercept and then stub the response, and then it happens when UI react with the network request. Is it possible to generate pact file with Cypress by making the request without UI interaction? Our API integration(e2e) test is using Cypress to making network request, and then verify the response. Cypress won’t be able to intercept those since it’s not the request coming from UI.

As long as you’re using the

cy.intercept

I believe so. Have you tried it? @Shuying Lin is that right?

cy.intercept setup the rule to intercept the incoming request from browser (application network layer), but if we directly use cy.request to send out network request, then the request is coming from physical layer, and cypress won’t be able to intercept it.

, the reason we are using cypress to run our API e2e was because we are trying to use the same tool for all our testing. UI e2e, API e2e, etc.

😱

ah that’s good point, so I guess the bi-direction with cypress plugin probably won’t work with our micro services, but we can probably adopt it with our front end UI test.

that’s probably a better use case

yea, our micro services been running integrate test with Cypress, and it worked well. But now we are trying to adopt contact testing, and saw the cypress plugin