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

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

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

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

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

这个问题发布已经有一段时间了，但仍然没有答案…

Kleolb02的答案很好。我会试着讲得更详细一些。

有一种方法，我在c#代码中练习过。对于单元测试，您应该能够编写可重复的测试，这是多线程代码中的最大挑战。因此，我的回答旨在将异步代码强制到同步工作的测试装置中。

这是Gerard Meszaros的书“xUnit测试模式”中的一个想法，被称为“Humble Object”(第695页):必须将核心逻辑代码和任何闻起来像异步代码的东西分开。这将产生一个用于核心逻辑的类，它同步地工作。

这将使您能够以同步方式测试核心逻辑代码。您可以绝对控制对核心逻辑进行调用的时间，因此可以进行可重复的测试。这就是分离核心逻辑和异步逻辑的好处。

这个核心逻辑需要由另一个类来包装，这个类负责异步接收对核心逻辑的调用，并将这些调用委托给核心逻辑。产品代码将只通过该类访问核心逻辑。因为这个类应该只委托调用，所以它是一个没有太多逻辑的非常“愚蠢”的类。因此，您可以将这个异步工作类的单元测试保持在最小值。

在此之上的任何测试(测试类之间的交互)都是组件测试。同样在这种情况下，如果你坚持使用“Humble Object”模式，你应该能够完全控制时间。

如果你正在测试简单的new Thread(runnable).run() 您可以模拟Thread来按顺序运行可运行对象

例如，如果被测试对象的代码像这样调用一个新线程

Class TestedClass {
    public void doAsychOp() {
       new Thread(new myRunnable()).start();
    }
}

然后模拟new Threads并按顺序运行runable参数会有所帮助

@Mock
private Thread threadMock;

@Test
public void myTest() throws Exception {
    PowerMockito.mockStatic(Thread.class);
    //when new thread is created execute runnable immediately 
    PowerMockito.whenNew(Thread.class).withAnyArguments().then(new Answer<Thread>() {
        @Override
        public Thread answer(InvocationOnMock invocation) throws Throwable {
            // immediately run the runnable
            Runnable runnable = invocation.getArgumentAt(0, Runnable.class);
            if(runnable != null) {
                runnable.run();
            }
            return threadMock;//return a mock so Thread.start() will do nothing         
        }
    }); 
    TestedClass testcls = new TestedClass()
    testcls.doAsychOp(); //will invoke myRunnable.run in current thread
    //.... check expected 
}

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

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

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

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

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

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

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

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

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

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

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

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

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