为了测试并发性问题,我想使用单元测试在两个不同的线程上同时调用相同的方法。实际上我可能想同时在多个线程上调用相同的方法。
我正在使用微软内置的VS2008单元测试仪。
我的想法是我会锁定一个对象,然后同步设置每个线程,这些线程会立即等待锁定然后释放锁定,这将允许所有线程访问共享资源并测试代码的能力正确处理多个线程。
以前有人这样做过吗?我在这里采取合理的方法吗?
答案 0 :(得分:5)
我之前已经完成了这项工作,即使结果并非总是可重复,但它们可以突出显示代码中的问题或错误。
我不使用Microsoft的单元测试,但我更喜欢MbUnit,它具有ThreadedRepeat属性,允许您指定要运行的线程数。它使整个多线程测试更容易,只需编写测试并添加属性。
答案 1 :(得分:3)
这种方法的问题在于结果不可重复。因此,如果您的代码中存在错误,多次调用相同的测试会导致(例如)某些情况下的死锁,而在其他情况下则不会。
答案 2 :(得分:1)
如果使用单元测试来测试多线程代码,那么你可能做错了。
对于初学者,您无法保证两种方法同时运行;这意味着您的测试不能保证您的代码有效。
您可能可以通过插入sleep命令来测试您的方法在多线程环境中是否正常工作,但这对于单元测试来说太过于干扰;它实际上是一个概念证明,而不是我确定代码的某些部分按预期工作后作为单元测试留下的东西。
多线程测试本身很好,可以在单元测试花费大量时间时加快单元测试,但单元测试对于测试小型隔离方法至关重要。
您可能会考虑进行压力测试,但这是“从外部”完成的,而不是像单元测试那样从“内部”完成。这意味着您在服务器上再次编写客户端并从多台计算机上运行数千次,测试整个系统而不是单个隔离方法。压力测试有两个主要优点。首先,压力测试用于准确找到在实时情况下一次运行一次的缺陷类型,其次,因为它们是“从外部”完成的,它们更好地重现线程将穿过您的方式应用
单元测试在我的opionion中对于测试多线程代码与通过调试器运行代码是不利的 - 当一个线程正在等待你启动下一步,其他线程将超时,你将永远不会有真正的-life repro。
总而言之,并非所有东西都应该经过单元测试;概念验证测试是确保线程安全集合真正是线程安全的好方法,压力测试非常适合发现多线程代码中的错误。
答案 3 :(得分:0)
对于单元测试,我认为这不是最理想的,因为Kibbee表示它可能会或可能不会成功。您需要运行数百或数千次,即使这样,即使存在竞争条件,您也可能永远不会遇到错误。
如果你试图确保没有死锁,你可以看看typemock racer:http://www.typemock.com/learn_about_typemock_racer.html我没有经验,但听起来它可以检测到很多死锁。