Why would one need "async" support for MS Unit Test if Task.Result can be used?

Question

I'm a bit puzzled here...I have a test method which does a call to an async method and I changed the signature to async Task. Works.

[TestMethod]
public async Task TestIt()
{
  bool result = await service.SomethingAsync();
  Assert(result);
}

Now I read all over the web that support for async is required in unit tests and is now also in NUnit. But why is that so important? I can write the test like this, using the Result property which will wait for Task completion:

[TestMethod]
public void TestIt()
{
  bool result = service.SomethingAsync().Result;
  Assert(result);
}

Answer 1

Result has an unfortunate side effect of wrapping all exceptions in AggregateException. This makes testing the error path much more painful.

But even if you decide you could live with that, you still have the problem of calling multiple async methods within a single test; i.e., if your test setup also requires async work. To do it in a blocking way, you'd have to either refactor your test method into a separate async method, or wrap it in an async delegate and either execute it directly or toss it into Task.Run. Not impossible, but not convenient either.

Finally, there's the problem of async components that assume a one-thread-at-a-time context. Examples include ViewModels and WebAPI/MVC controllers. At that level, those components often assume that they don't need to synchronize access to asynchronously shared data because they're never executed in a free-threaded context. Until you unit test, that is. The common approach is to give those unit tests a single-threaded context, e.g., installing a Dispatcher on the unit test thread. In that case, a Result will deadlock. There are ways around this but, again, it's not convenient to write that code.

The bottom line is that async unit tests don't make it possible; they make it convenient. And anything that encourages unit testing (especially for trickier things like async) is a good idea. :)