假设你有这样的代码:

public void method() {
        CompletableFuture.runAsync(() -> {
            //logic
            //logic
            //logic
            //logic
        });
    }

试着把它重构成这样:

public void refactoredMethod() {
    CompletableFuture.runAsync(this::subMethod);
}

private void subMethod() {
    //logic
    //logic
    //logic
    //logic
}

之后，用下面的方法测试subMethod:

org.powermock.reflect.Whitebox.invokeMethod(classInstance, "subMethod"); 

这不是一个完美的解决方案，但它测试了异步执行中的所有逻辑。

对于测试异步方法，我发现一个非常有用的方法是在测试对象的构造函数中注入Executor实例。在生产中，执行器实例被配置为异步运行，而在测试中，它可以被模拟为同步运行。

所以假设我试图测试异步方法Foo#doAsync(Callback c)，

class Foo {
  private final Executor executor;
  public Foo(Executor executor) {
    this.executor = executor;
  }

  public void doAsync(Callback c) {
    executor.execute(new Runnable() {
      @Override public void run() {
        // Do stuff here
        c.onComplete(data);
      }
    });
  }
}

在生产中，我会用Executors.newSingleThreadExecutor() Executor实例构造Foo，而在测试中，我可能会用执行以下操作的同步执行器构造它

class SynchronousExecutor implements Executor {
  @Override public void execute(Runnable r) {
    r.run();
  }
}

现在异步方法的JUnit测试非常干净

@Test public void testDoAsync() {
  Executor executor = new SynchronousExecutor();
  Foo objectToTest = new Foo(executor);

  Callback callback = mock(Callback.class);
  objectToTest.doAsync(callback);

  // Verify that Callback#onComplete was called using Mockito.
  verify(callback).onComplete(any(Data.class));

  // Assert that we got back the data that we expected.
  assertEquals(expectedData, callback.getData());
}

值得一提的是，《并发实践》中有一章非常有用，它描述了一些单元测试方法，并给出了解决问题的方案。

恕我直言，让单元测试创建或等待线程是一种糟糕的实践。您希望这些测试在瞬间运行。这就是为什么我想提出一个测试异步进程的两步方法。

测试您的异步进程是否正确提交。您可以模拟接受异步请求的对象，并确保提交的作业具有正确的属性，等等。 测试你的异步回调是否在做正确的事情。在这里，您可以模拟最初提交的作业，并假设它已正确初始化，并验证您的回调是否正确。

您可以尝试使用await库。这使得测试您所谈论的系统变得很容易。

尽可能避免使用并行线程进行测试(大多数时候都是这样)。这只会使您的测试不可靠(有时通过，有时失败)。

只有当你需要调用其他库/系统时，你可能不得不等待其他线程，在这种情况下，总是使用await库而不是Thread.sleep()。

永远不要在测试中只调用get()或join()，否则您的测试可能会在CI服务器上一直运行，以防将来永远无法完成。在调用get()之前，始终在测试中首先断言isDone()。对于CompletionStage，就是. tocompletablefuture (). isdone()。

当你像这样测试一个非阻塞方法时:

public static CompletionStage<String> createGreeting(CompletableFuture<String> future) {
    return future.thenApply(result -> "Hello " + result);
}

那么你不应该仅仅通过在测试中传递一个完整的Future来测试结果，你还应该确保你的方法doSomething()不会通过调用join()或get()来阻塞。如果使用非阻塞框架，这一点尤其重要。

要做到这一点，测试一个未完成的未来，你手动设置为完成:

@Test
public void testDoSomething() throws Exception {
    CompletableFuture<String> innerFuture = new CompletableFuture<>();
    CompletableFuture<String> futureResult = createGreeting(innerFuture).toCompletableFuture();
    assertFalse(futureResult.isDone());

    // this triggers the future to complete
    innerFuture.complete("world");
    assertTrue(futureResult.isDone());

    // futher asserts about fooResult here
    assertEquals(futureResult.get(), "Hello world");
}

这样，如果您将future.join()添加到doSomething()，测试将失败。

如果你的服务使用ExecutorService，比如applyasync(…， executorService)，然后在你的测试中注入一个单线程的executorService，比如来自guava的:

ExecutorService executorService = Executors.newSingleThreadExecutor();

如果你的代码使用forkJoinPool，比如applyasync(…)，重写代码使用ExecutorService(有很多好的理由)，或者使用await。

为了缩短示例，我将BarService设置为测试中作为Java8 lambda实现的方法参数，通常它将是您将模拟的注入引用。