我喜欢编写两个或多个测试方法在并行线程上执行，并且每个方法都调用被测对象。我一直在使用Sleep()调用来协调来自不同线程的调用顺序，但这并不真正可靠。它也慢得多，因为你必须睡足够长的时间，时间通常是有效的。

我从编写FindBugs的同一组中找到了多线程TC Java库。它允许您在不使用Sleep()的情况下指定事件的顺序，而且它是可靠的。我还没试过。

这种方法的最大限制是它只允许您测试您怀疑会引起麻烦的场景。正如其他人所说，您确实需要将多线程代码隔离到少量简单类中，以便有希望彻底测试它们。

一旦您仔细测试了您预计会导致问题的场景，那么在类中抛出一堆并发请求的不科学测试是寻找意外问题的好方法。

更新:我已经玩了一些多线程TC Java库，它工作得很好。我还将它的一些特性移植到一个。net版本，我称之为TickingTest。

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

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

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

测试线程代码和非常复杂的系统的另一种方法是通过模糊测试。 它不是很好，也不能找到所有的东西，但它可能是有用的，而且操作简单。

引用:

Fuzz testing or fuzzing is a software testing technique that provides random data("fuzz") to the inputs of a program. If the program fails (for example, by crashing, or by failing built-in code assertions), the defects can be noted. The great advantage of fuzz testing is that the test design is extremely simple, and free of preconceptions about system behavior. ... Fuzz testing is often used in large software development projects that employ black box testing. These projects usually have a budget to develop test tools, and fuzz testing is one of the techniques which offers a high benefit to cost ratio. ... However, fuzz testing is not a substitute for exhaustive testing or formal methods: it can only provide a random sample of the system's behavior, and in many cases passing a fuzz test may only demonstrate that a piece of software handles exceptions without crashing, rather than behaving correctly. Thus, fuzz testing can only be regarded as a bug-finding tool rather than an assurance of quality.

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

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

我用与处理任何单元测试相同的方式处理线程组件的单元测试，即使用反转控制和隔离框架。我在. 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注入到组件中，并使用所选的隔离框架使线程在测试期间的行为符合我的预期。

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

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

题外话:

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