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