到目前为止，我已经避免了测试多线程代码的噩梦，因为它似乎是一个太大的雷区。我想知道人们是如何测试依赖于线程的代码以获得成功执行的，或者人们是如何测试那些仅在两个线程以给定方式交互时才会出现的问题的?
对于今天的程序员来说，这似乎是一个非常关键的问题，恕我直言，将我们的知识集中在这个问题上是很有用的。
当前回答
我在测试多线程代码时也遇到了严重的问题。然后我在Gerard Meszaros的“xUnit测试模式”中找到了一个非常酷的解决方案。他描述的模式被称为Humble object。
基本上，它描述了如何将逻辑提取到独立的、易于测试的组件中，该组件与环境解耦。在你测试了这个逻辑之后，你可以测试复杂的行为(多线程，异步执行，等等…)
其他回答
我曾经有过测试线程代码的不幸任务，这绝对是我写过的最难的测试。
在编写测试时，我使用委托和事件的组合。基本上，它都是关于使用PropertyNotifyChanged事件和WaitCallback或某种轮询的ConditionalWaiter。
我不确定这是否是最好的方法，但它对我来说是有效的。
一个简单的测试模式可以用于一些(不是所有!)用例，就是多次重复相同的测试。例如，假设你有一个方法:
def process(input):
# Spawns several threads to do the job
# ...
return output
创建一堆测试:
process(input1) -> expect to return output1
process(input2) -> expect to return output2
...
现在将每个测试运行多次。
如果流程的实现包含一个微小的错误(例如死锁、竞态条件等)，出现的概率为0.1%，那么运行1000次测试，则该错误至少出现一次的概率为64%。运行测试10000次，得到>99%的概率。
Pete Goodliffe有一个关于线程代码单元测试的系列。
是很困难的。我采用了更简单的方法，尽量将线程代码从实际测试中抽象出来。皮特确实提到了我分手的方式是错误的但我要么是正确的，要么就是我很幸运。
等待在帮助您编写确定性单元测试时也很有用。它允许您等待系统中的某个状态更新。例如:
await().untilCall( to(myService).myMethod(), greaterThan(3) );
or
await().atMost(5,SECONDS).until(fieldIn(myObject).ofType(int.class), equalTo(1));
它还支持Scala和Groovy。
await until { something() > 4 } // Scala example
确实很难!在我的(c++)单元测试中，我按照使用的并发模式将其分解为几个类别:
Unit tests for classes that operate in a single thread and aren't thread aware -- easy, test as usual. Unit tests for Monitor objects (those that execute synchronized methods in the callers' thread of control) that expose a synchronized public API -- instantiate multiple mock threads that exercise the API. Construct scenarios that exercise internal conditions of the passive object. Include one longer running test that basically beats the heck out of it from multiple threads for a long period of time. This is unscientific I know but it does build confidence. Unit tests for Active objects (those that encapsulate their own thread or threads of control) -- similar to #2 above with variations depending on the class design. Public API may be blocking or non-blocking, callers may obtain futures, data may arrive at queues or need to be dequeued. There are many combinations possible here; white box away. Still requires multiple mock threads to make calls to the object under test.
题外话:
在我所做的内部开发人员培训中，我教授了并发的支柱和这两种模式，作为思考和分解并发问题的主要框架。显然还有更先进的概念，但我发现这组基础知识可以帮助工程师摆脱困境。正如上面所描述的，它还会导致代码更具单元可测试性。
