This is the simple solution I came up with for now, I'll see if I can find
some time to get a PR into the Grpc.Core.Testing package with a better API
and doubles for the other interfaces. In the meanwhile perhaps this will
help someone :-)
class MockClientRequestStream<T> : IAsyncStreamReader<T>
{
private readonly IEnumerator<T> _enumerator;
public MockClientRequestStream(IEnumerable<T> data)
{
_enumerator = data.GetEnumerator();
}
public void Dispose()
{
_enumerator.Dispose();
}
public Task<bool> MoveNext(CancellationToken cancellationToken)
{
return Task.FromResult(_enumerator.MoveNext());
}
public T Current => _enumerator.Current;
}
On Wednesday, 15 May 2019 13:54:50 UTC+1, Jan Tattermusch wrote:
>
> It shouldn't be hard to implement your own test doubles for
> IServerStreamWriter, IClientStreamWriter, IAsyncStreamReader
> the functionality of those interfaces is pretty trivial, so it shouldn't
> be much of an overhead writing those.
>
> If you come up with something that you believe that can be reused by
> others, you can consider contributing to tho Grpc.Core.Testing package -
> https://github.com/grpc/grpc/tree/master/src/csharp/Grpc.Core.Testing (the
> package doesn't have much right now, but it's been meant to provide
> tools/test doubles to simplify unit testings).
>
>
> On Thursday, May 9, 2019 at 12:29:43 PM UTC+2, Joseph Vaughan wrote:
>>
>> Hi Christopher,
>>
>>
>>
>> Thank you for your response, I had a feeling that this is the way that it
>> should be approached. In my case the RPC is fairly straight forward, but
>> I’d still like it to be testable, so perhaps using DataFlow blocks as you
>> have is suitable. I’ll look into it thanks.
>>
>>
>> On Tuesday, 7 May 2019 22:35:52 UTC+1, Christopher Warrington - MSFT
>> wrote:
>>>
>>> On Tuesday, May 7, 2019 at 1:57:34 AM UTC-7, Joseph Vaughan wrote:
>>>
>>> > Does anyone have any good solutions for substituting in the
>>> > IServerStreamWriter, IClientStreamWriter, IAsyncStreamReader types,
>>> either
>>> > under a mock framework or with test stubs?
>>>
>>> In my team's code base, we've divorced the business logic from the gRPC
>>> handler implementation by using DataFlow [1] blocks. The business logic
>>> doesn't even contain a reference to the gRPC assemblies at all. It does
>>> use
>>> Proto messages. This makes the business logic easily unit testable.
>>>
>>> We have small adapters from the gRPC interfaces to Dataflow blocks. The
>>> service handlers use these adapters to bridge from IServerStreamWriter &
>>> friends to the business logic's input/output types. These adapters get
>>> tested in our server integration tests.
>>>
>>> We have four different projects of interest here:
>>>
>>> * core (class library): business logic
>>> * core-tests (unit tests): tests for code in core
>>> * service (executable): reads config, starts gRPC service, gRPC to
>>> business
>>> logic adapter (service handlers), Dataflow blocks adapter
>>> * service-tests (integration tests): stands up full service using
>>> single-box
>>> config and exercises it
>>>
>>> [1]:
>>> https://docs.microsoft.com/en-us/dotnet/standard/parallel-programming/dataflow-task-parallel-library
>>>
>>> --
>>> Christopher Warrington
>>> Microsoft Corp.
>>>
>>>
--
You received this message because you are subscribed to the Google Groups
"grpc.io" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to grpc-io+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/grpc-io/12118507-1350-4c1b-ac9d-7d1360d11bb2%40googlegroups.com.
