单元测试并发软件 - 你做什么？

Question

随着软件越来越多并发,您如何使用单元测试来处理类型的核心行为(不是并行行为,只是核心行为)？

在过去的好时光中,你有一个类型,你打电话给它,你检查了它返回的内容和/或它所调用的其他内容.

现在,你调用一个方法,实际的工作计划在下一个可用的线程上运行; 你不知道什么时候它会真正启动并调用其他东西 - 更重要的是,其他东西也可能是并发的.

你怎么处理这个？你抽象/注入并发调度程序(例如抽象任务并行库并在单元测试中提供假/模拟)？

您遇到了哪些资源帮助了您？

---

编辑

我编辑了这个问题,强调测试类型的正常行为(忽略用于利用多核的任何并行机制,例如TPL)

---

Answer 1

免责声明:我在西雅图的一家小型创业公司Corensic工作.我们有一个名为Jinx的工具,用于检测代码中的并发错误.我们在测试阶段时它是免费的,所以你可能想要查看它.(http://www.corensic.com/)

简而言之,Jinx是一个非常薄的虚拟机管理程序,在激活后,会在处理器和操作系统之间滑入.Jinx然后智能地执行切片并运行各种线程计时的模拟以查找错误.当我们发现会导致错误发生的特定线程时序时,我们会在您的计算机上将该时间设置为"真实"(例如,如果您使用的是Visual Studio,则调试器将在此时停止).然后,我们指出代码中导致错误的区域.Jinx没有误报.当它检测到错误时,它肯定是一个错误.

Jinx适用于Linux和Windows,以及本机代码和托管代码.它是语言和应用程序平台无关的,可以使用您现有的所有工具.

如果您查看,请向我们发送有关哪些有效且无效的反馈.我们已经在一些大型开源项目上运行Jinx,并且已经看到Jinx可以发现错误比仅仅压力测试代码快50-100倍的情况.

Answer 2

竞争条件和死锁的单元测试领域相对较新，并且缺乏好的工具。

我知道有两个这样的工具都处于早期 alpha/beta 阶段：

• 微软的国际象棋
• 类型模拟赛车手

另一种选择是尝试编写一个“压力测试”，这会导致死锁/竞争条件出现，创建多个实例/线程并并排运行它们。这种方法的缺点是，如果测试失败，则很难重现它。我建议在测试和生产代码中使用日志，以便您能够了解发生了什么。