https://github.com/pact-foundation/pact-mock_service
This only covers a suggestion of how to add Protobuf support for just the response functionality of the mock_service.
The sugegsted workflow for creating consumer tests with protobuf is assumed to be as follows:
- Write the
Contract.proto
file which describes the message which will be the payload for an HTTP response from a provider. - Generate the Google.Protobuf code which handles the messages in the .proto.
- Program the interaction into the mock_server by posting
interaction-post-payload.json
to it. - The
file_descriptor_set_b64
is a representation which contains the details of how to encode/decode thePerson
message - it's possible to construct these from generated code. Given .proto definitions often don't live in the repo of the application, we need an approach that doesn't rely on the .proto contents (there are other reasons too why the file descriptor set is the best thing here). - Generate the ruby code required to encode/decode using
protoc
, put this in the temp directory. - When the consumer test code attempts to access
/hello
, the mock_service knows that the response programmed is protobuf: it then loads all the generated proto code, and exercises the right methods to encode the response in protobuf.
- The intention is to make
content_type
optional, assuming JSON if it's not present, andprotobuf_context
would also be optional in theresponse
, which makes this new feature possible without breaking existing clients. - I think if this were to be a supported thing, then a mention of JSON-izeable formats, protobuf specifically, would be a good idea.
The following aspects still need to be clarified:
- The request decoding in the mock_service.
- Both encoding and decoding in pact-provider-verifier. I haven't attempted to lay out my strategy for these, as I think it will be fairly clear that what I'm suggesting here is a thin wrapper around all of the existing functionality. Given all I'm tyring to do with protobuf is encode/decode when data is going on / coming off the wire, and the data remains JSON otherwise - we're not talking about a change that's super invasive.
Given that expected requests/responses are transformed straight into JSON, there are no protobuf-specific concerns WRT matching functionality.
None of the code included in this gist is pretending to be production ready: it's just an illustration.
I have a working (very early) prototype working based on this gist: if you approve of this approach, I'm happy to flesh it out and create a PR and likewise do the same for the pact-provider-verifier.