到目前为止，我已经避免了测试多线程代码的噩梦，因为它似乎是一个太大的雷区。我想知道人们是如何测试依赖于线程的代码以获得成功执行的，或者人们是如何测试那些仅在两个线程以给定方式交互时才会出现的问题的?
对于今天的程序员来说，这似乎是一个非常关键的问题，恕我直言，将我们的知识集中在这个问题上是很有用的。
当前回答
看看我的相关答案在
为自定义Barrier设计一个Test类
它偏向于Java，但对选项进行了合理的总结。
总而言之(我认为)，它不是使用一些花哨的框架来确保正确性，而是如何设计你的多线程代码。拆分关注点(并发性和功能性)有助于提高信心。测试引导的面向对象软件的发展比我能更好地解释一些选项。
静态分析和形式化方法(参见并发性:状态模型和Java程序)是一种选择，但我发现它们在商业开发中用处有限。
不要忘记，任何加载/浸泡风格的测试都很少能保证突出问题。
好运！
其他回答
下面的文章提出了两种解决方案。包装一个信号量(CountDownLatch)，并添加诸如从内部线程外部化数据之类的功能。实现此目的的另一种方法是使用线程池(请参阅兴趣点)。
喷头-高级同步对象
(如果可能的话)不要使用线程，使用actor /活动对象。易于测试。
对于Java，请参阅JCIP的第12章。有一些具体的例子，可以编写确定性的多线程单元测试，以至少测试并发代码的正确性和不变量。
用单元测试“证明”线程安全要危险得多。我相信在各种平台/配置上进行自动化集成测试会更好。
如果你正在测试简单的new Thread(runnable).run() 您可以模拟Thread来按顺序运行可运行对象
例如，如果被测试对象的代码像这样调用一个新线程
Class TestedClass {
public void doAsychOp() {
new Thread(new myRunnable()).start();
}
}
然后模拟new Threads并按顺序运行runable参数会有所帮助
@Mock
private Thread threadMock;
@Test
public void myTest() throws Exception {
PowerMockito.mockStatic(Thread.class);
//when new thread is created execute runnable immediately
PowerMockito.whenNew(Thread.class).withAnyArguments().then(new Answer<Thread>() {
@Override
public Thread answer(InvocationOnMock invocation) throws Throwable {
// immediately run the runnable
Runnable runnable = invocation.getArgumentAt(0, Runnable.class);
if(runnable != null) {
runnable.run();
}
return threadMock;//return a mock so Thread.start() will do nothing
}
});
TestedClass testcls = new TestedClass()
testcls.doAsychOp(); //will invoke myRunnable.run in current thread
//.... check expected
}
上周我花了大部分时间在大学图书馆学习并发代码的调试。核心问题是并发代码是不确定的。通常，学术调试可以分为三个阵营之一:
Event-trace/replay. This requires an event monitor and then reviewing the events that were sent. In a UT framework, this would involve manually sending the events as part of a test, and then doing post-mortem reviews. Scriptable. This is where you interact with the running code with a set of triggers. "On x > foo, baz()". This could be interpreted into a UT framework where you have a run-time system triggering a given test on a certain condition. Interactive. This obviously won't work in an automatic testing situation. ;)
现在，正如上面评论者所注意到的，您可以将并发系统设计成更确定的状态。然而，如果你做得不好，你就又回到了设计顺序系统的问题上。
我的建议是，专注于制定一个非常严格的设计协议，规定什么是线程，什么不是线程。如果你限制了你的接口，使元素之间的依赖最小化，那就容易多了。
祝你好运，继续解决这个问题。
