To fully grasp what we will be covering you should have a basic knowledge of software testing and understand what the following terms mean:
gRPC is an open source protocol used for remote procedure calls which was initially developed at Google. It uses HTTP/2 for transport and most typically uses Protocol Buffers to define a message schema. It provides features such as authentication, bidirectional streaming and blocking or nonblocking bindings. It is possible to generate cross-platform client and server code for many languages.
Development teams choose to use gRPC because:It is possible to use gRPC in a manner very similar to standard HTTP, where a client sends a single request message to the server and the server responds with a single response message. This mode is referred to as "unary streaming" in gRPC. It can work very well for a large number of use cases where the performance benefit of bidirectional streaming is unnecessary.
Let us focus on a typical communication pattern where two systems communicate with unary gRPC request and responses:
It is typical for one team to develop a gRPC service that is consumed by one or more other teams. For example System A may contain a gRPC client that communicates with System B that contains a gRPC server. This introduces an issue: how can the client teams test their client system against the service system that does not exist yet?
To reduce the cost of delay, you can choose to simulate the gRPC service in System B before the service team have finished their implementation. By defining the API up front by using the proto file definitions, both the client and server teams can work in parallel.
With Traffic Parrot, you can take the proto API definition and use it to produce a virtual service that can mock and simulate gRPC responses. This way, your client team can test System A in isolation without having to wait for the server team to finish working on System B.
This will allow us to test System A in isolation in both typical and hypothetical situations. You will be able to simulate gRPC responses that are expected to be seen in production environments, but also non-typical error responses or failure scenarios that would usually be hard to reproduce. You can do that by configuring Traffic Parrot to respond with response messages of your choice.
Traffic Parrot supports using the proto API definition file to produce a mock service. You can use the user interface to define mock responses and simulate behaviour using the advanced templating features.
Let’s go through an example of how to simulate a gRPC service that is specified in the following proto:message Item {
int32 sku = 1;
int32 quantity = 2;
}
enum Status {
SUCCESS = 0;
ERROR = 1;
}
message OrderStatus {
Status status = 1;
string message = 2;
}
service Order {
rpc Purchase(Item) returns (OrderStatus) {}
}
The application we are testing is a simple shopping application that can be used to order items from a shop server:
The systems communicate using unary gRPC:
We can use Traffic Parrot instead of the real shop server:
on
the Add/Edit page and change the mapping
This tutorial has focused on the simple case where there is one request message and one response message.
However, with gRPC you benefit from HTTP/2 which means that you will have asynchronous streaming support.
The possible streaming modes are:Traffic Parrot currently has full support for unary streaming mode and partial support for the server and bidirectional streaming modes. For more information see the gRPC documentation.
