We are writing unit tests for async code using MSTest and Moq.
So we have some code that looks something like :
var moq = new Mock<Foo>();
moq.Setup(m => m.GetAsync())
.Returns(Task.FromResult(10));
Or like this on projects that have a more recent version of Moq
var moq = new Mock<Foo>();
moq.Setup(m => m.GetAsync())
.ReturnsAsync(10);
Looking at the Moq implementation of ReturnsAsync :
public static IReturnsResult<TMock> ReturnsAsync<TMock, TResult>(this IReturns<TMock, Task<TResult>> mock, TResult value) where TMock : class
{
TaskCompletionSource<TResult> completionSource = new TaskCompletionSource<TResult>();
completionSource.SetResult(value);
return mock.Returns(completionSource.Task);
}
Both methods seem to be the same under the hood. Both create a TaskCompletionSource, call SetResult and return the Task
So far so good.
But short running async methods are optimized to act synchronously. This seems to imply that TaskCompletionSource is always synchronous, which would also seem to suggest that context handling and any related issues that can occur would never happen.
So if we had some code that was doing some async no-no's, like mixing awaits, Wait() and Result, that these problems would not be detected in unit testing.
Would there be any advantage to creating an extension method which always yields control? Something like :
public async Task<T> ReturnsYieldingAsync<T>(T result)
{
await Task.Yield();
return result;
}
In this case we would have a method that is guaranteed to execute asynchronously.
The perceived advantage would be detecting bad asynchronous code. For example, it could catch any deadlocking or exception swallowing during unit testing.
I am not 100% sure this is the case, so I would really be interested in hearing what the community has to say.
