About problem

In the process of developing any software product, one of the key stages is creating tests, as they help ensure the system operates correctly. An integral part of this process is dependency mocking, which allows for isolating the components being tested and minimizing the influence of external factors.

Mocking is an approach that involves creating simulations of system objects or components used during testing. Essentially, mocks are fake implementations of real objects. They are employed to isolate the code under test from its dependencies, whether these are databases, external APIs, or other services. Using mocks helps focus on testing the
logic of a specific component without being reliant on external systems, which might be unavailable, unstable, or complex to emulate.

With the advancement of technology and the shift towards microservice architectures, developers increasingly choose gRPC as a means of service-to-service communication due to its performance, scalability, and сonvenience.

gRPC (Google Remote Procedure Call) is a powerful framework for remote procedure calls (RPC) developed by Google. It enables efficient and fast connections between applications written in different programming languages by leveraging the HTTP/2 protocol and compact binary serialization through Protocol Buffers. This approach makes gRPC an ideal solution for modern distributed systems.

However, with the widespread adoption of gRPC, developers face a new challenge: integrating gRPC clients into tests. Since a gRPC client inevitably becomes one of the core dependencies of an application, it also becomes a critical part of the testing process—and, unfortunately, often introduces additional complexities. Simulating gRPC requests and their
handling requires the use of mocks or specialized tools, which may feel unfamiliar to those accustomed to more traditional REST APIs.

Therefore, a well-thought-out approach to mocking gRPC dependencies is a crucial step towards achieving comprehensive test coverage and ensuring the stability of the system as a whole.

In this article, we will focus on mocking gRPC clients, as the process of mocking the server-side (ServiceBase) does not require any specific actions. Typically, testing the server-side is similar to testing controllers in web applications and is already familiar to many developers.

gRPC clients, on the other hand, are more complex to test due to the nature of their interactions with the server. This process requires modeling various call scenarios, each differing in how they handle data streams. Let's review the main scenarios:

1. UnaryCall - A standard request-response call. The client sends a request to the server and receives a single response. This scenario is the most common and resembles traditional REST calls.
2. ClientSideStreaming - A call where the client sends a stream of data to the server. The stream is built progressively, and data is not sent all at once, as is the case with UnaryCall.
3. ServiceSideStreaming - A call where the client sends a single request to the server and receives a stream of data in response. The server's response is delivered in parts rather than as a single package, as in UnaryCall.
4. DuplexStreaming - The most complex scenario, where the client and server simultaneously exchange streams of data. This requires implementing bidirectional communication, making both development and testing more challenging.

Each of these scenarios introduces unique challenges to the process of mocking and testing, making the gRPC client a more complex object to work with compared to traditional REST clients.

Options for Mocking gRPC Clients

1. Moq - One of the most popular mocking libraries in the .NET ecosystem. It allows you to emulate gRPC client methods, define return values, and verify method calls.
2. Grpc.Core.Testing - A library specifically designed for testing gRPC clients. It provides helper classes like MockCall to simplify mock setup.
3. Grpc.Net.Testing.Moq - An extension of the Moq library optimized for Grpc.Net.Client. It is a convenient tool that helps minimize the amount of test code required.
4. Grpc.Net.Testing.NSubstitute - An alternative to the previous option, built on the NSubstitute library. It is ideal for those who prefer its syntax for mocking.

Each of these approaches has its strengths and unique features. Depending on the tools and requirements of your project, you can select the most suitable method for creating gRPC client mocks. In the following sections, we will delve deeper into each option to help you decide which one best meets your needs.

In our testing, we will not consider cases where values are precomputed outside the delegate passed to the Returns<> method.

Let's prepare a sample client

First, let's create a small sample client that will serve as the foundation for the mocking process. This client will be simple yet functional enough to demonstrate the key principles and approaches to testing with mocks.

The client will act as a starting point for developing and testing various interaction scenarios.

syntax = "proto3";

package tests;

service TestService {
  rpc Simple(TestRequest) returns(TestResponse);
  rpc SimpleClientStream(stream TestRequest) returns(TestResponse);
  rpc SimpleServerStream(TestRequest) returns(stream TestResponse);
  rpc SimpleClientServerStream(stream TestRequest) returns(stream TestResponse);
}

message TestRequest {
  int32 val = 1;
}
message TestResponse {
  int32 val = 1;
}

The created service includes four methods, each demonstrating different interaction scenarios typical for gRPC. These methods serve as examples for exploring key service operation models and testing their functionality. Here's a description of each:

1. Simple - UnaryCall
   
   This method implements a standard request-response interaction. It accepts data from the client and returns an identical response. It's a straightforward example, perfect for demonstrating the basic principles of gRPC.

2. SimpleClientStream - ClientSideStreaming
   
   This method is designed to handle a stream of data sent by the client. Its task is to calculate the sum of all transmitted values and return it as the result. This illustrates a model where the client sends data incrementally, and the server responds with an aggregated result.

3. SimpleServerStream - ServiceSideStreaming
   
   This method demonstrates a model where the server returns a stream of data in response to a single client request. The method generates and sends N messages to the client based on the parameters of the request. This approach is often used for transmitting large volumes of data.

4. SimpleClientServerStream - DuplexStreaming
   
   The most complex and powerful interaction scenario. This method accepts a stream of data from the client, sums it up, and sends the result back as N messages. This example showcases bidirectional interaction, where the client and server exchange data simultaneously.

Simply use Moq

For this implementation, we will exclusively use the Moq library, which is one of the most popular and powerful tools in the .NET ecosystem for creating mocks.

UnaryCall

One of the simplest and most intuitive methods for mocking is the UnaryCall scenario. Its essence lies in the classic "request-response" interaction model, where the client sends a request to the server and expects a single response.

This approach forms the foundation for many systems and scenarios, making it an excellent starting point for learning the mocking process. Its simplicity allows you to focus on the key aspects of testing without having to deal with the complexities of stream-based interactions.

In this example, we will demonstrate how to use Moq to emulate the behavior of a UnaryCall method and configure it to correctly process requests and return the expected results.

[Fact]
public void SimpleTest()
{
    // Arrange
    var mock = new Mock<TestService.TestServiceClient>(MockBehavior.Strict);

    mock
        .Setup(c => c.Simple(It.IsAny<TestRequest>(), It.IsAny<Metadata>(), It.IsAny<DateTime?>(), It.IsAny<CancellationToken>()))
        .Returns<TestRequest, Metadata, DateTime?, CancellationToken>((r, _, _, _) => new TestResponse { Val = r.Val });

    var client = mock.Object;

    var testRequest = new TestRequest { Val = 42 };

    // Act
    var response = client.Simple(testRequest);

    // Assert
    response.Val.Should().Be(testRequest.Val);
}

[Fact]
public async Task SimpleAsyncTest()
{
    // Arrange
    var mock = new Mock<TestService.TestServiceClient>(MockBehavior.Strict);

    mock
        .Setup(c => c.SimpleAsync(It.IsAny<TestRequest>(), It.IsAny<Metadata>(), It.IsAny<DateTime?>(), It.IsAny<CancellationToken>()))
        .Returns<TestRequest, Metadata, DateTime?, CancellationToken>(
            (r, _, _, _) => new AsyncUnaryCall<TestResponse>(
                responseAsync: Task.FromResult(new TestResponse { Val = r.Val }),
                responseHeadersAsync: Task.FromResult(new Metadata()),
                getStatusFunc: () => Status.DefaultSuccess,
                getTrailersFunc: () => [],
                disposeAction: () => { }));

    var client = mock.Object;

    // Act
    var request = new TestRequest { Val = 42 };
    var response = await client.SimpleAsync(request);

    // Assert
    response.Val.Should().Be(request.Val);
}

Even a seemingly simple scenario, like mocking a UnaryCall in its asynchronous version, can feel somewhat challenging due to the need to work with AsyncUnaryCall. This class requires specifying multiple parameters, such as tasks for the response, headers, status, and metadata, which significantly increases the workload.

If you aim to implement more complex scenarios, for example, configuring the method's return value based on the parameters of the incoming Request, the task becomes even more complicated. In such cases, you need to dynamically create instances of AsyncUnaryCall<TestResponse>, which adds more code and makes the testing infrastructure more complex.

This can lead to additional time and resource costs for maintaining the tests, especially as the number of such methods grows or if they involve intricate data processing logic.

ClientSideStreaming

This scenario is more complex as it requires handling a stream of incoming messages. Unlike a simple "request-response" call, you need to account for the sequence of data sent by the client. This inevitably makes the mocking code more extensive and harder to comprehend.

In this example, we will emulate a service behavior where all incoming parameters are processed and summed, with the resulting sum returned as the response. This approach requires configuring the mocks to handle each message in the stream correctly, which adds an extra layer of complexity to the implementation of the tests.

To execute this task successfully, it is crucial not only to set up the mock properly but also to ensure that it accurately models the real service's behavior, particularly in the context of streaming data. This will help not only to validate the application's logic but also to uncover potential issues in data processing early in the development cycle.

[Fact]
public async Task SimpleClientStreamTest()
{
    // Arrange
    var mock = new Mock<TestService.TestServiceClient>(MockBehavior.Strict);

    var sum = 0;

    var taskCompletionSource = new TaskCompletionSource<TestResponse>();

    var streamWriter = new Mock<IClientStreamWriter<TestRequest>>(MockBehavior.Strict);
    streamWriter
        .Setup(c => c.WriteAsync(It.IsAny<TestRequest>()))
        .Callback<TestRequest>(m => sum += m.Val)
        .Returns(Task.CompletedTask);
    streamWriter
        .Setup(c => c.CompleteAsync())
        .Callback(() => taskCompletionSource.SetResult(new TestResponse { Val = sum }))
        .Returns(Task.CompletedTask);

    var asyncClientStreamingCall = new AsyncClientStreamingCall<TestRequest, TestResponse>(
        requestStream: streamWriter.Object,
        responseAsync: taskCompletionSource.Task,
        responseHeadersAsync: Task.FromResult(new Metadata()),
        getStatusFunc: () => Status.DefaultSuccess,
        getTrailersFunc: () => [],
        disposeAction: () => { });

    mock
        .Setup(c => c.SimpleClientStream(It.IsAny<Metadata>(), It.IsAny<DateTime?>(), It.IsAny<CancellationToken>()))
        .Returns(asyncClientStreamingCall);

    var client = mock.Object;

    var requests = Enumerable
        .Range(1, 10)
        .Select(i => new TestRequest { Val = i })
        .ToArray();

    // Act
    var call = client.SimpleClientStream();
    await call.RequestStream.WriteAllAsync(requests);

    // Assert
    var response = await call.ResponseAsync;

    var expected = requests.Sum(c => c.Val);

    expected.Should().Be(response.Val);
}

In this scenario, there arises a need to explicitly define a TaskCompletionSource, which allows deferring the execution of the response calculation until a specific moment. This approach enables delivering the result to the client only after explicitly calling the CompleteAsync method, making it useful for modeling asynchronous behavior.

However, such an implementation significantly complicates the code and increases its size, which can be problematic for large projects or when frequent test updates are required. These additional steps demand more time and resources and also increase the likelihood of errors in the test logic.

ServiceSideStreaming

This example examines a scenario where the client sends a single request containing a number, based on which the server generates and returns a stream of N responses, each including that number.

This approach is commonly used to implement server-side streaming, where the server gradually sends data to the client in response to a single request. It can be useful in cases where large amounts of data need to be transmitted, but not all at once — for instance, when delivering data in batches, updates, or processing results.

When mocking this scenario, it is essential to properly configure the method's behavior to return a data stream that accurately models the real service's functionality. This involves generating a sequence of responses based on the input value and setting up asynchronous behavior to simulate incremental data delivery.

Such tests help ensure that the client logic correctly processes streaming responses and can handle delays, sequential processing, and other aspects of working with data streams effectively.

[Fact]
public async Task SimpleServerStreamTest()
{
    // Arrange
    var mock = new Mock<TestService.TestServiceClient>(MockBehavior.Strict);

    mock
        .Setup(
            c => c.SimpleServerStream(
                It.IsAny<TestRequest>(),
                It.IsAny<Metadata>(),
                It.IsAny<DateTime?>(),
                It.IsAny<CancellationToken>()))
        .Returns<TestRequest, Metadata, DateTime?, CancellationToken>(
            (r, _, _, _) =>
            {
                var reader = new Mock<IAsyncStreamReader<TestResponse>>(MockBehavior.Strict);

                var current = reader.SetupSequence(c => c.Current);
                var moveNext = reader.SetupSequence(c => c.MoveNext(It.IsAny<CancellationToken>()));

                for (var i = 0; i < r.Val; i++)
                {
                    moveNext = moveNext.ReturnsAsync(true);
                    current = current.Returns(new TestResponse { Val = r.Val });
                }

                moveNext = moveNext.ReturnsAsync(false);

                return new AsyncServerStreamingCall<TestResponse>(
                    responseStream: reader.Object,
                    responseHeadersAsync: Task.FromResult(new Metadata()),
                    getStatusFunc: () => Status.DefaultSuccess,
                    getTrailersFunc: () => [],
                    disposeAction: () => { });
            });

    var client = mock.Object;

    var testRequest = new TestRequest { Val = 42 };

    // Act
    var call = client.SimpleServerStream(testRequest);

    // Assert
    var responses = await call.ResponseStream
        .ReadAllAsync()
        .ToArrayAsync();

    responses.Should()
        .HaveCount(testRequest.Val).And
        .AllSatisfy(c => c.Val.Should().Be(testRequest.Val));
}

As evident from this scenario, testing server-side streaming requires defining a complex delegate that involves detailed configuration of the Mock<IAsyncStreamReader<>> object. This object plays a crucial role as it handles the sequential delivery of stream data, ma