gRPC Mock and Testing

[kinlane]

I would like to do a story on gRPC mocking and testing, then use for a blog post, as well as prepare for a Breaking Changes TL;DR episode.

[lbroudoux]

gRPC mocking and testing is supported in Microcks since 1.3.0 (see https://microcks.io/blog/microcks-1.3.0-release/#a-hug-to-grpc-fans)

To support gRPC, Microcks uses the Multi-Artifacts support feature that allows API mock definitions to be built from different artifacts:

• A primary artifacts may hold API structural elements like name, version and operations descriptions,
• Some secondary artifacts may hold additional elements like metadata and examples.

So basically, for gRPC we rely on 2 (or 3) complementary artifacts that are:

• A standard gRPC / Protocol Buffer .proto file that acts as primary artifact,
• A Postman Collection file that acts as a secondary artifact for holding request/response examples,
• An optional APIMetadata file thats acts as a secondary artifact for holding additional metadata and dispatching rules for mock requests.

Check the reference doc here for details.

Some points on Mocking

• The nice thing using Postman is that request/response examples can be easily edited using JSON format. Microcks will take care of doing the Protobuf / JSON conversion for you in its mocking engine.

• As a gRPC service exposes a sole HTTP/2 endpoint, the dispatch to correct mock response should be done depending on the request body content. Microcks uses a JSON_BODY dispatcher for that - see reference. So users have to defined these dispatching rules either through the UI, the Microcks API or by importing an APIMetadata artifact.

• All the templating expressions - and even Postman functions - are available within gRPC mocking context.

Some points on Testing

• Testing gRPC in Microcks is syntactical contract testing. It means that it executes example requests on a specific endpoint being under test and then checks that received responses can be correctly deserialized using the Protobuf Schema we loaded as primary artifact. This means we're able to check that endpoint is conformant with service version schema but also check backward compatibilities issues on newer service versions.

• As with all other protocols, tests requests, responses and validation issues are recorded within Microcks. Requests and responses are managed as JSON if we're able to deserialize it, otherwise managed as raw bytes.

• Templating expressions and functions can also be used at testing level to integrate some levels of variations in the dataset that is applied to the system under test.