有一篇关于这个主题的文章，在示例代码中使用Rust作为语言:

https://medium.com/@polyglot_factotum/rust-concurrency-five-easy-pieces-871f1c62906a

总而言之，诀窍在于编写并发逻辑，使其对涉及多个执行线程的非确定性具有健壮性，使用通道和condvars等工具。

然后，如果这就是您构建“组件”的方式，那么测试它们的最简单方法是使用通道向它们发送消息，然后阻塞其他通道以断言组件发送某些预期的消息。

链接到的文章完全使用单元测试编写。

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版本 测试并发代码:简要介绍两种主要方法:蛮力(压力测试)或确定性(使用不变量)

上周我花了大部分时间在大学图书馆学习并发代码的调试。核心问题是并发代码是不确定的。通常，学术调试可以分为三个阵营之一:

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. ;)

现在，正如上面评论者所注意到的，您可以将并发系统设计成更确定的状态。然而，如果你做得不好，你就又回到了设计顺序系统的问题上。

我的建议是，专注于制定一个非常严格的设计协议，规定什么是线程，什么不是线程。如果你限制了你的接口，使元素之间的依赖最小化，那就容易多了。

祝你好运，继续解决这个问题。

我用与处理任何单元测试相同的方式处理线程组件的单元测试，即使用反转控制和隔离框架。我在. net领域进行开发，开箱即用的线程(以及其他东西)很难(我可以说几乎不可能)完全隔离。

因此，我写的包装器看起来像这样(简化):

public interface IThread
{
    void Start();
    ...
}

public class ThreadWrapper : IThread
{
    private readonly Thread _thread;
     
    public ThreadWrapper(ThreadStart threadStart)
    {
        _thread = new Thread(threadStart);
    }

    public Start()
    {
        _thread.Start();
    }
}
    
public interface IThreadingManager
{
    IThread CreateThread(ThreadStart threadStart);
}

public class ThreadingManager : IThreadingManager
{
    public IThread CreateThread(ThreadStart threadStart)
    {
         return new ThreadWrapper(threadStart)
    }
}

从那里，我可以很容易地将IThreadingManager注入到组件中，并使用所选的隔离框架使线程在测试期间的行为符合我的预期。

到目前为止，这对我来说工作得很好，我对线程池，系统中的东西使用相同的方法。环境，睡眠等等。

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

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.

题外话:

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