为什么不使用 async/await 关键字时异步单元测试会失败？

Question

根据this discussion，下面两种方法应该没有区别：

public async Task Foo()
{
    await DoSomethingAsync();
}

public Task Foo()
{
    return DoSomethingAsync();
}

实际上，对于非常简单的方法， 不带 async/await 关键字的调用似乎是首选，因为它们消除了一些开销。

但是，这显然在单元测试中并不总是有效。

MSTest

[TestClass]
public class AsyncTest
{
    [TestMethod]
    public async Task Test1()
    {
        await Task.Delay(0);
    }

    [TestMethod]
    public Task Test2()
    {
        return Task.Delay(0);
    }
}

NUnit

[TestFixture]
public class AsyncTest
{
    [Test]
    public async Task Test1()
    {
        await Task.Delay(0);
    }

    [Test]
    public Task Test2()
    {
        return Task.Delay(0);
    }
}

XUnit

public class AsyncTest
{
    [Fact]
    public async Task Test1()
    {
        await Task.Delay(0);
    }

    [Fact]
    public Task Test2()
    {
        return Task.Delay(0);
    }
}

• 在所有情况下，Test1 通过。
• 在 MSTest 中，Test2 出现在测试运行程序中，但它没有运行。

• 在 NUnit 中，Test2 被忽略，消息为：

  测试方法具有非空返回类型，但没有预期结果

• 在 XUnit 中，Test2 通过。

由于在所有情况下任务仍然是等待的，async 关键字影响 NUnit 和 MSTest 测试运行器的原因是什么？也许是一些反射问题？

Answer 1

听起来那些测试运行器可能正在使用反射来检查返回Task 的方法是否真的是异步方法。这并不意味着该方法的行为会有所不同如果它们被运行 - 但它们只是没有被运行。

就像这样说：

public string Name { get; set; }

相当于：

private string name;
public Name { get { return name; } set { name = value; } }

就行为而言，它们在逻辑上是相同的，但如果你足够努力地反思，你就能分辨出不同之处。在这种特殊情况下，还有其他更细微的差异，但适用相同的一般原则。

看起来在当前的 NUnit 代码中（在撰写本文时）检测位于 AsyncInvocationRegion.cs。

诚然，编写返回Task 但不使用异步方法的单元测试至少不寻常 - 但远非不可能。