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

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

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

您可以使用EasyMock。使测试实例线程安全

我在测试多线程代码时也遇到了严重的问题。然后我在Gerard Meszaros的“xUnit测试模式”中找到了一个非常酷的解决方案。他描述的模式被称为Humble object。

基本上，它描述了如何将逻辑提取到独立的、易于测试的组件中，该组件与环境解耦。在你测试了这个逻辑之后，你可以测试复杂的行为(多线程，异步执行，等等…)

假设在“多线程”代码下是指某些东西

有状态和可变的 由多个线程访问/修改 同时

换句话说，我们讨论的是测试自定义的有状态线程安全类/方法/单元——这应该是当今非常罕见的野兽。

因为这个野兽很罕见，首先我们需要确保有充分的理由来写它。

步骤1。考虑在相同的同步上下文中修改状态。

现在很容易编写可组合的并发和异步代码，其中IO或其他慢操作卸载到后台，但共享状态在一个同步上下文中更新和查询。例如，async/await任务和。net中的Rx等等——它们都是可测试的设计，“真正的”任务和调度程序可以被取代，以使测试具有确定性(但这超出了问题的范围)。

这听起来可能很有限，但这种方法效果惊人。以这种风格编写整个应用程序是可能的，而不需要使任何状态线程安全(我这样做)。

步骤2。如果在单个同步上下文上操作共享状态是绝对不可能的。

确保轮子没有被重新发明/肯定没有标准的替代方案可以适应这项工作。代码应该是非常内聚的，包含在一个单元中，例如，它很有可能是一些标准的线程安全数据结构的特殊情况，如哈希映射或集合或其他。

注意:如果代码很大/跨越多个类并且需要多线程状态操作，那么设计很有可能是不好的，请重新考虑第1步

步骤3。如果达到了这一步，那么我们需要测试我们自己的自定义有状态线程安全类/方法/单元。

我非常诚实:我从来没有为这样的代码编写过合适的测试。大多数情况下，我在第一步就成功了，有时在第二步。上次我不得不编写自定义线程安全代码是在很多年前，那是在我采用单元测试之前/可能我不需要用目前的知识来编写它。

如果我真的必须测试这样的代码(最终，真正的答案)，那么我会尝试下面的一些事情

Non-deterministic stress testing. e.g. run 100 threads simultaneously and check that end result is consistent. This is more typical for higher level / integration testing of multiple users scenarios but also can be used at the unit level. Expose some test 'hooks' where test can inject some code to help make deterministic scenarios where one thread must perform operation before the other. As ugly as it is, I can't think of anything better. Delay-driven testing to make threads run and perform operations in particular order. Strictly speaking such tests are non-deterministic too (there's a chance of system freeze / stop-the-world GC collection which can distort otherwise orchestrated delays), also it is ugly but allows to avoid hooks.

看看我的相关答案在

为自定义Barrier设计一个Test类

它偏向于Java，但对选项进行了合理的总结。

总而言之(我认为)，它不是使用一些花哨的框架来确保正确性，而是如何设计你的多线程代码。拆分关注点(并发性和功能性)有助于提高信心。测试引导的面向对象软件的发展比我能更好地解释一些选项。

静态分析和形式化方法(参见并发性:状态模型和Java程序)是一种选择，但我发现它们在商业开发中用处有限。

不要忘记，任何加载/浸泡风格的测试都很少能保证突出问题。

好运！