听着，要做到这一点并不容易。我正在做一个本来就是多线程的项目。事件来自操作系统，我必须并发地处理它们。

处理测试复杂的多线程应用程序代码的最简单方法是:如果它太复杂而无法测试，那么您做错了。如果您有一个单独的实例，其中有多个线程作用于它，并且您无法测试这些线程相互踩在一起的情况，那么您的设计需要重做。它既简单又复杂。

有许多方法可以为多线程编程，以避免线程同时通过实例运行。最简单的方法是使所有对象都是不可变的。当然，这通常是不可能的。因此，您必须在设计中确定线程与同一实例交互的地方，并减少这些地方的数量。通过这样做，您可以隔离多线程实际发生的几个类，从而降低测试系统的总体复杂性。

但是您必须意识到，即使这样做，您仍然不能测试两个线程相互践踏的每一种情况。要做到这一点，您必须在同一个测试中并发地运行两个线程，然后准确地控制它们在任何给定时刻执行的行。你能做的就是模拟这种情况。但这可能需要您专门为测试编写代码，这充其量是迈向真正解决方案的半步。

测试代码是否存在线程问题的最好方法可能是对代码进行静态分析。如果您的线程代码没有遵循有限的线程安全模式集，那么您可能会遇到问题。我相信VS中的代码分析确实包含了一些线程的知识，但可能不多。

看，就目前的情况来看(可能还会持续很长一段时间)，测试多线程应用程序的最佳方法是尽可能降低线程代码的复杂性。最小化线程交互的区域，尽可能地进行测试，并使用代码分析来识别危险区域。

一个简单的测试模式可以用于一些(不是所有!)用例，就是多次重复相同的测试。例如，假设你有一个方法:

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%的概率。

等待在帮助您编写确定性单元测试时也很有用。它允许您等待系统中的某个状态更新。例如:

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

我曾经有过测试线程代码的不幸任务，这绝对是我写过的最难的测试。

在编写测试时，我使用委托和事件的组合。基本上，它都是关于使用PropertyNotifyChanged事件和WaitCallback或某种轮询的ConditionalWaiter。

我不确定这是否是最好的方法，但它对我来说是有效的。

Testing MT code for correctness is, as already stated, quite a hard problem. In the end it boils down to ensuring that there are no incorrectly synchronised data races in your code. The problem with this is that there are infinitely many possibilities of thread execution (interleavings) over which you do not have much control (be sure to read this article, though). In simple scenarios it might be possible to actually prove correctness by reasoning but this is usually not the case. Especially if you want to avoid/minimize synchronization and not go for the most obvious/easiest synchronization option.

我遵循的一种方法是编写高度并发的测试代码，以使潜在的未检测到的数据竞争有可能发生。然后我运行这些测试一段时间:)我曾经无意中看到一个演讲，一些计算机科学家展示了一个这样做的工具(根据规格随机设计测试，然后疯狂地运行它们，同时检查定义的不变量是否被破坏)。

顺便说一下，我认为测试MT代码的这一方面在这里还没有提到:确定可以随机检查的代码不变量。不幸的是，找到这些不变量也是一个相当困难的问题。此外，它们在执行期间可能不会一直保持，因此您必须找到/强制执行可以期望它们为真的执行点。将代码执行到这样的状态也是一个难题(并且本身可能会引起并发性问题)。呼，这太难了!

一些有趣的链接可供阅读:

确定性交错:允许强制执行某些线程交错，然后检查不变量的框架 jMock Blitzer:压力测试同步 assertConcurrent:压力测试同步的JUnit版本 测试并发代码:简要介绍两种主要方法:蛮力(压力测试)或确定性(使用不变量)

运行多个线程并不困难;这是小菜一碟。不幸的是，线程通常需要彼此通信;这就是困难所在。

最初发明的允许模块之间通信的机制是函数调用;当模块A想要与模块B通信时，它只调用模块B中的一个函数。不幸的是，这对线程不起作用，因为当你调用一个函数时，该函数仍然运行在当前线程中。

为了克服这个问题，人们决定采用一种更原始的通信机制:只声明一个特定的变量，并让两个线程都可以访问该变量。换句话说，允许线程共享数据。分享数据是人们自然而然想到的第一件事，这似乎是一个不错的选择，因为它看起来非常简单。我是说，能有多难，对吧?会出什么问题呢?

竞态条件。这就是可能、也将会出错的地方。

当人们意识到他们的软件由于竞争条件而遭受随机的、不可复制的灾难性失败时，他们开始发明复杂的机制，如锁和比较-交换，旨在防止此类事情的发生。这些机制属于广义的“同步”范畴。不幸的是，同步有两个问题:

这是很难做到的，所以很容易出现bug。 它是完全不可测试的，因为您无法测试竞态条件。

精明的读者可能会注意到“非常容易出现bug”和“完全不可测试”是一个致命的组合。

现在，在自动化软件测试的概念变得流行之前，我上面提到的机制已经被行业的大部分人发明和采用了;所以，没有人知道这个问题有多致命;他们只是认为这是一个很难的主题，需要高手程序员，每个人都能接受。

如今，无论我们做什么，我们都把测试放在第一位。所以，如果某些机制是不可测试的，那么使用该机制就是不可能的。因此，同步已经失宠;现在还在练的人已经很少了，而且练的人一天比一天少。

没有同步线程就不能共享数据;然而，最初的要求不是共享数据;它允许线程之间进行通信。除了共享数据之外，还存在其他更优雅的线程间通信机制。

其中一种机制是消息传递，也称为事件。

对于消息传递，整个软件系统中只有一个地方利用了同步，那就是我们用来存储消息的并发阻塞队列收集类。(我们的想法是，我们应该至少能把那一小部分做对。)

消息传递的优点是它不受竞态条件的影响，并且是完全可测试的。