单元测试VS异步代码随机测试的随想

　　查看英文原文： Thoughts on Unit Testing vs Ad-hoc Testing with Asynchronous Code

　　众多“任务+异步/等待”模式有意思的特性之一是用户能够比较容易地对任何操作的结果进行装饰。微软的 Lucian Wischik 展示了如何采用这种特性的优势，以使得您的端到端测试结果更加健壮。

　　使用Mr.Flakey 就跟在 Windows 8 或者 Windows Phone 8 应用的每一个 await 语句后面加上“.Flakey ()”一样简单。

Dim r = Await http.GetStringAsync (uri) .Flakey ()

　　启用之后，每个异步调用都将会触发一个对话框，用户可以选择点击“ok”按钮， 这样会像正常一样返回结果，或者点击“fail”按钮来模拟一个网络或者服务器异常。

　　为什么使用这种随机测试而不编写一套全面的单元测试用例呢？Lucian 解释如下:

　　单元测试：以我个人的经验，单元测试在测试分布式算法中并不是非常有效。测试的时候需要花费相当多的努力建立环境（比如，模拟网络环境），而且这种测试方法注定不够全面，并且以我个人经验来看，单元测试实在是不太适合于发现分布式环境下的缺陷。我怀疑这是因为程序员的大脑经常会沿着他们算法中“正确”的路径进行思考，而不太擅长面对其他各种错误路径。

　　（想一想：当你查看并发程序代码的时候，你是不是一个仅仅通过查看代码就能够发现竞争条件的人？你团队中有人能够做到这个吗？你曾经写过一个发现竞争条件的单元测试用例吗？至少我还没有过）

　　随机测试： 发现缺陷的一个非常棒的方式是交互式的随机测试。如果通过用户界面就能非常容易地模拟错误，你就几乎可以将自己的脑袋设置成自动导航模式，随机地点击界面上的各个位置，很快就能发现应用程序运行行为不正确的地方。

　　我被 Leslie Lampor 在 1990 年研究的“时态逻辑检查器”迷住了-- 这是一种自动探索巨大指数空间可能性的方法（类似于我们在分布式算法中所面对的问题）。他所发现的在可能性空间“自动随机遍历”最后在实践中证明确实能够发现所有的缺陷，并且远远比对每一个可能性进行详尽测试更加有效。