I have a question about testing contracts for aggregating clients (Service Oriented Architectures, GraphQL, etc.). Basically, those clients will make a series of server facing calls, doing something with the data each time (joins, filters, etc.) Is that something that can/should be specified via pact contracts (e.g., the server can provide X's, Y's, and Z's according to contract ABC as needed by the client, with visa versa also being true). Use case: client returns colors for cars available in year, does the server support the underlying calls for the client. 1. Client gets request for colors in a year 2. Client queries service for manufactures that produced cars that year 3. Client makes a series of service calls for models from each manufacture for that year 4. Client makes a service call for colors for each model of that year 5. Client returns the unique set of colors across all makes/models for that year Note, calls 2,3,4 may happen on the same server, different servers, etc. They may occur in the client or at an aggregation node (SOA). If pact supported this, I can see there might be implementation gotchas on the client tests. My train of though is that the pact responses might not be able to excite the logic required by the aggregation client. To say it specifically, according to the PACT contract, generated responses match a contract, but that contract does not extend between services. In practice, that means a join might not work because IDs are not sync'd, filters don't apply, etc. So philosophically, is PACT the right framework to test aggregate clients? Or, is it only the right tool to check the individual service calls that would feed into an aggregate client?

Sorry Adam, we’ve been busy with a release over here and have been a bit behind catching up