unit-testing - 单元测试预期和非预期死锁行为的明智策略

Question

我想要一些关于如何测试一些可以阻塞的对象的想法，等待另一个参与者。要测试的特定单元是参与者之间的 channel ，参与者本身是用于测试目的的模拟装置。

验证参与者是否在预期时发生死锁会很好，但这对我来说并不是非常重要，因为在死锁之后发生的事情可以合理地描述为未定义。

更重要的是验证参与者定义的交互没有死锁。

无论哪种情况，我都不确定最佳测试策略应该是什么。我目前的想法是让测试运行程序为每个参与者启动一个线程，睡一会儿，然后发现子线程是否已经返回。在它们没有及时返回的情况下，假设它们已经死锁，并安全地终止线程，并且测试失败(或者如果预期死锁则成功)。

这感觉有点概率论，因为可能有各种原因(但不太可能)导致线程可能需要比预期更长的时间才能完成。有没有其他好的方法来解决这个问题？

编辑:我确信测试中的稳健性会很好，但我认为我不需要它。我正在考虑三个级别的测试确定性。

“实际行为已证明与预期行为相符”不会发生死锁

N次测试未出现“实际行为符合预期行为”死锁

“实际行为与预期行为一致” N 个测试在预期期限内完成

第一个当然是通过的有值(value)的测试，但 ShiDoiSi 的回答说明了它的不切实际。第二个明显比第一个弱，但仍然很难；您如何确定进程网络实际上已死锁？我不确定这比第一个更容易证明(可能要困难得多)

最后一个更像我的想法。

Answer 1

可靠地测试死锁的唯一方法是检测锁定子系统以检测和报告它们。上次我不得不这样做时，我们构建了一个调试版本，它记录了哪些线程持有哪些锁，并在每次锁获取调用时检查潜在的死锁。在有大量锁定的系统中，它可能是一项重量级操作，但我们发现它非常有值(value)，因此我们重新组织了子系统，以便我们可以在运行时通过开关打开和关闭它，即使在生产构建中也是如此。