A philosophical conundrum Given that we have Service A produced by team A, which consumes Service B produced by team B. Service B publishes a RESTful interface, and additionally publishes a DotNet library (ServiceBClient) which implements the networking layer for us. We utilize ServiceBClient in Service A. However, that API is low level and complex, so we write a "ServiceBManager" class in Service A which hides the ServiceBClient produced by team B.

┌─────────────────────────────────┐   ┌──────────────────────────┐
│Service A                        │   │Service B                 │
│       ┌──────────┐ ┌──────────┐ │   │ ┌───────────┐            │
│       │ServiceB  │ │ServiceB  │ │   │ │REST API   │            │
│       │Manager   │►│Client    ├─┼───┤►│           │            │
│       │          │ │          │ │   │ │Team B     │            │
│       │Team A    │ │Team B    │ │   │ └───────────┘            │
│       └──────────┘ └──────────┘ │   │                          │
│Team A                           │   │Team B                    │
└─────────────────────────────────┘   └──────────────────────────┘

The Pact philosophy suggests that the Pact consumer tests should be on ServiceBClient. However, that is maintained by Team B which violates the principle that Pact is about the contract between the consumer and the producer. However, writing the Pact tests against ServiceBManager violates the principle that each consumer test should test a single call. Thoughts on the correct course of action here?

Is the ServiceB client that is consumed by Service A a wrapper around calls to the Rest interface of Service B? I think we have a similar situation. We have a routing service and a routing service client (for us a different repo). We have an agent which consumes the client which gives it extra endpoints that can be called over rest. Initially we had tests between the routing service and the client but that proved to have holes as we could never guarantee the latest version of the client was being used by the agent, so the test wasn’t that valuable. In the end we decided to do the contract between the routing service and the agent instead so we could at least validate the client functionality works when consumed by the agent

This blog is perhaps a bit dated, but attempts to talk to some of these points: https://pactflow.io/blog/should-i-write-contract-tests-for-client-sdks/ I think it’s probably fine to test the ServiceBManager, even if it makes a few calls. In those Pact tests, if you can, you could always attempt to stub network calls all but the “primary” scenario so that it’s closer to the philosophical aims of Pact. That might be easier said than done

Thank you both very much for your replies. It is super helpful to see what others have had success with in the past. I have been writing example tests at both the ServiceBManager and ServiceBClient level to get a feel for how they would look. I am definitely leaning towards writing the tests at the ServiceBManager level because I feel that would give the most accurate representation of Service A's expectations. I ran into an interesting issue that maybe deserves its own thread. Team B actually produces multiple services. In one case a single method in ServiceBClient calls Service B and utilizes a URL in the response to call Service C. I feel like I need to call this method twice, once testing only the call to Service B and mocking Service C, and once mocking Service B and testing the call to Service C. Otherwise there would be no way to pass appropriate pacts to each of Service B and C? Are there any examples of doing this out there?

You're welcome!