Hey folks, a question somewhat related to the OpenAPI question above. We have a pair of services communicating over http, but instead of calling provider endpoints directly, the consumer imports a client library (generated) from the provider side and makes the call to that library via simply calling a function with a parameter struct. This way consumer doesn't really know that the communication is over http and theoretically the communication protocol can change over time (though practically it's unlikely). We can deconstruct the endpoints from a generated client and write an HTTP pact test, but I'm wondering if we can do something like a message pact, but for synchronous calls to not rely on client's implementation details?

oh hello! Sorry I missed this

no worries 🙂

interesting idea. I guess you could try the message pact concept, albeit it feels like the HTTP testing path is still the way to go

interesting idea in the second approach. I wonder if we can somehow auto-generate a pact-like SDK from the provider's SDK which would look something like:

providerTestLib.NewPactBuilder(t).
    GivenWithParameter(....).  // same as pact
    GetObject("interaction name").  // function name corresponding to the function name in the generated SDK
    WithRequest(
        // specify request object in terms of matchers - but it has to be translated into whether it's a query or body, and it's specific to a function we're calling
     ).
     WillRespondWith(
        matcher.StructMatcher{
                "x": matcher.Like("y")
       }
      ).
     ExecuteTest(t, func(config consumer.MockServerConfig) error {
         // instantiate client, make a call
    })

Yeah, the shipping of a TCK along with the SDK seems like a plausible approach. I’ve not tried it in practice though