鉴于.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");
2017-11-30 15:26:34
