鉴于.NET Framework 4.5后.NET增加了对 async/await 的支持，本文讨论的异步内容均基于async/await

  客户端界面开发，多线程是逃不了的话题，而多线程的加入势必对程序的稳定性带来挑战，单元测试就显得更为重要。相对于同步代码的测试，多线程单元测试有更多细节需要注意。

async void 和 async Task。

  假设某一天你运气不好，需要为类似如下的方法补充单元测试：

public static bool Changed;public static async void ChangeAsync()
{await Task.Run(() =>{Task.Delay(1000);Changed = true;});
}

你发现，要测试此方法需要用一些奇葩的方式，比如：

[TestMethod()]
public void ChangeAsyncTest_OriginalFalse_ChangeToTrue()
{AsyncClient.Changed = false;AsyncClient.ChangeAsync();Thread.Sleep(1100);Assert.IsTrue(AsyncClient.Changed);
}

显然，这种延时等待是极其恶心的，如果ChangeAsync方法返回的不是void而是Task，我们就可以愉快的await了：

[TestMethod()]
public async Task ChangeAsyncTest_OriginalFalse_ChangeToTrue()
{AsyncClient.Changed = false;await AsyncClient.ChangeAsync();Assert.IsTrue(AsyncClient.Changed);
}

需要特别注意的是，在异步单元测试方法中也必须返回Task，这是MSTest的约定，否则这个测试方法无法运行起来。（实际上MSTest也需要使用返回的Task来收集异常，关于这部分更多内容可以参见Async/Await最佳实践）

抛弃ExpectedException

  在测试程序是否按照预期的抛出了异常，我们常常会用ExpectedException，这家伙有一个问题，它是对整个测试方法的方法体做捕获，也就是说测试方法中的非action代码抛出了异常依然能够被ExpectedException捕获，这就造成潜在的bug，为了解决此问题，在MSTest V2之前往往需要写一些辅助方法，但MSTest V2断言库中增加了Assert.ThrowsExceptionAsync和Assert.ThrowsException，可以精确的定位在哪段代码中抛出了异常。假设我们的被测代码跟下面类似：

public static async Task ChangeAsync()
{await Task.Run(() =>{throw new InvalidOperationException();});
}

测试代码可以这样写：

[TestMethod()]
public async Task ChangeAsyncTest_ThrowInvalidOperationException()
{await Assert.ThrowsExceptionAsync<InvalidOperationException>(async () =>{await AsyncClient.ChangeAsync();});
}

异步方法mock

  在moq中，异步方法的mock也是极其简单的，假设有这样的接口：

public interface ITextReader
{Task<string> ReadTextAsync();
}

测试代码中mock其返回结果可以有如下两种写法：

var mockTextReader = new Mock<ITextReader>();//可以这样
mockTextReader.Setup(x => x.ReadTextAsync()).Returns(async ()=>await Task.FromResult("mockValue"));//也可以这样
mockTextReader.Setup(x => x.ReadTextAsync()).ReturnsAsync(()=> "mockValue");

date: 2017-11-30 15:26:34