Sin*_*ion 6 language-agnostic verification unit-testing deadlock
我想要一些关于如何测试一些可以阻塞的对象,等待另一个参与者的想法.要测试的特定单元是参与者之间的通道.参与者本身是用于测试目的的模拟装置.
很高兴验证参与者在预期时会发生死锁,但这对我来说并不是非常重要,因为在死锁之后发生的事情可以合理地描述为未定义.
更重要的是验证参与者定义的交互不会死锁.
在任何一种情况下,我都不确定最佳测试策略应该是什么.我目前的想法是让测试运行器为每个参与者触发一个线程,休眠一段时间,然后发现子线程是否已经返回.在它们没有及时返回的情况下,假设它们已经死锁,并且安全地终止线程,并且测试失败(或者如果预期死锁则成功).
这感觉有点可能性,因为可能存在各种原因(但不太可能),线程可能需要比预期更长的时间才能完成.有没有其他好方法来解决这个问题？
编辑:我确信测试的稳健性会很好,但我认为我不需要它.我正在考虑三个级别的测试确定性.
第一个当然是一个有价值的测试,但ShiDoiSi的答案说明了这一点的不切实际.第二个明显弱于第一个,但仍然很难; 如何确定进程网络实际上已陷入僵局？我不确定这比第一次更容易证明(可能更难)
最后一个更像我的想法.
可靠地测试死锁的唯一方法是检测锁定子系统以检测和报告它们.我最后一次必须这样做,我们构建了一个调试版本,它记录了哪些线程保持锁定并检查每次锁定获取调用的潜在死锁.它可以是一个具有大量锁定的系统中的重量级操作,但我们发现它非常有价值,我们重组了子系统,因此我们可以在运行时使用开关打开和关闭它,即使在生产版本中也是如此.
| 归档时间： |
|
| 查看次数： |
827 次 |
| 最近记录： |