Is there any general advice for consumer-driven contract tests when the request path includes a proxy/aggregator component? Our scenario is roughly SPA => BFF => ExtractionService • The BFF (backend for frontend) acts as a provider in the SPA => BFF interaction • The BFF acts a consumer in the BFF => ExtractionService interaction The BFF is basically just making requests "on behalf of " the SPA and relaying responses verbatim. There is a logical contract between the SPA and the ExtractionService. It seems wasteful to set up two sets of tests - particularly, the provider-state setup that influences the shape of the response

I think the advice has historically been "if it's just a pass-through, don't test it", but "if it has logic, test it". And there's a big grey area between those, usually yay Someone might have a more up-to-date answer, or even a docs/blog article to link, though . . .

Sure - but it is important that the logical contract between the SPA and the ExtractionService gets tested - whether transitively or directly

So yeah, in the grey area, there are questions like "will a smoke test suffice?" (i.e. if the service has connectivity, and we check a small number of requests, do we have confidence that the rest will be fine, too?). It greatly depends on how much logic/mapping there is.

So it seems our options are to either • lie, and publish an interaction between the SPA and the ExtractionService (no such interaction actually exists) ◦ It's kind of a white lie though, right? ....right? • Publish two sets of interactions (SPA -> BFF and BFF -> ExtractionService) with the pain that this entails

kinda

then it doesn't affect the contract, it's just an infrastructure dependency, that could be tested in other ways

To be clear, I'm not worried about not testing the pass-through layer. I'm more worried that we do test the (logical) contract between the SPA and the ExtractionService

But if there's any logic (e.g. body or URL transformations, filters on paths, WAF rules, splitting chunks of requests to different back-end services, etc), then it gets harder to decide where to draw the lines.

Thanks - gives me some things to think about.

that's a good start, then 😅 unfortunately, a lot of the interesting questions have very "it depends" answers 🙃

I have a solution for this, planned but not documented, as part of ContractCase

Essentially the idea is that you have “transforming verifications” - where you write the contract at the SPA, do the verification at the proxy, that verification produces and a transformed contract (which is asserted the same way as a regular client contract would be)

I remember you talking about it at lunch once, but I never fully followed it, specifically, how it solved the problem. There are two classes (broadly) of this problem: 1. Pure transform aka the classic API gateway (often, this is pure configuration/infra). The hard problem here, usually, is that there is little code to test and it can be cumbersome to setup the testing scenarios. 2. There is some more complex logic going on (combining APIs, orchestration, choreography, etc.). The problem here, is that if you are using tools like Layer7/Apigee/Axway etc. then you’re in a real spot because they are very hard to test, but you can’t get away with just mapping or ignoring bits because they do way to much. I posited a while back that for (1) we could potentially just allow a configuration file be uploaded from the provider that documents the mapping, and we somehow “overlay” that into the verification process. I like that terminology - and it describes a broader concept that could be reused, for sure.

Most cases are like “we swap the auth headers” or “we change the path” - those are easy. For the rest, you’d run the mock in a capture mode. Pact doesn’t support this, of course

For the rest, you’d run the mock in a capture mode.

which mock are we talking about here? The mock that the gateway would use? i.e. you would do a VCR style test?

The approach looks like this:

Mock Client (running the contract verification as normal)
   -> Proxy
        -> Mock Server (running contract definition, as you normally would at the client)

You would run the Mock Server in a "capture" mode, where you go "ok, capture the request, and return this response"