鉴于.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