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

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

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

(如果可能的话)不要使用线程，使用actor /活动对象。易于测试。

Pete Goodliffe有一个关于线程代码单元测试的系列。

是很困难的。我采用了更简单的方法，尽量将线程代码从实际测试中抽象出来。皮特确实提到了我分手的方式是错误的但我要么是正确的，要么就是我很幸运。

确实很难!在我的(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.

题外话:

在我所做的内部开发人员培训中，我教授了并发的支柱和这两种模式，作为思考和分解并发问题的主要框架。显然还有更先进的概念，但我发现这组基础知识可以帮助工程师摆脱困境。正如上面所描述的，它还会导致代码更具单元可测试性。

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

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

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

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

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

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

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

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