重新同步多线程集成测试

我最近在Captain Debug的Blog上偶然发现了一篇文章“ 同步多线程集成测试 ”。 该文章强调了设计涉及被测类以异步方式运行业务逻辑的集成测试的问题。 给出了这个人为的示例（我删除了一些评论）：

public class ThreadWrapper {
 
    public void doWork() {
 
        Thread thread = new Thread() {
            @Override
            public void run() {
 
                System.out.println("Start of the thread");
                addDataToDB();
                System.out.println("End of the thread method");
            }
 
            private void addDataToDB() {
                // Dummy Code...
                try {
                    Thread.sleep(4000);
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
            }
        };
 
        thread.start();
        System.out.println("Off and running...");
    }
 
}

这只是常见模式的一个示例，在该模式中，业务逻辑被委派给我们无法控制的某些异步作业池。 Roger Hughes （作者）列举了测试这种代码的几种技巧，包括：

• 测试方法中的任意（“足够长”） sleep()以确保后台逻辑完成
• 重构doWork() ，使其接受CountDownLatch并同意在作业完成时通知它
• 将上述方法@VisibleForTesting包私有且仅@VisibleForTesting
• “该”解决方案–重构doWork()使其可以接受任意Runnable 。 在测试中，我们可以包装此Runnable （装饰器模式）并等待内部Runnable完成

最后一个解决方案不错，但是它极大地改变了ThreadWrapper的职责。 现在，由调用者决定在先前ThreadWrapper完全封装业务逻辑时应异步执行哪种作业。 我并不是说这是一个糟糕的设计，但是它与原始方法有很大的不同。

待命性

如果不进行如此大规模的重构，我们可以编写测试吗？ 第一个解决方案涉及称为Awaitility的便捷库。 该库不是灵丹妙药，它只是定期评估给定条件并确保它在给定时间内得到满足。 您可能会编写一两次这样的代码，然后将它们包装在具有精心设计的API的库中。 因此，这是我们的初始方法：

import static com.jayway.awaitility.Awaitility.await;
import static java.util.concurrent.TimeUnit.SECONDS;
 
//...
 
await().atMost(10, SECONDS).until(recordInserted());
 
//...
 
private Callable<Boolean> recordInserted() {
    return new Callable<Boolean>() {
        @Override
        public Boolean call() throws Exception {
            return dataExists();
        }
    };
}

我认为这里没有什么可解释的。 dataExists()只是一个boolean方法，最初返回false但一旦后台任务（ addDataToDB() ）完成，最终将返回true 。 换句话说，我们假设后台任务引入了一些副作用，而dataExists()可以检测到该副作用。 顺便说一句，我碰巧安装了具有Lambda支持的JDK 8，而IntelliJ IDEA给了我这个很好的工具提示：

突然，我得到了建议的与Java 8兼容的替代方案：

private Callable<Boolean> recordInserted() {
    return () -> dataExists();
}

但是还有更多：

将我的代码转换为：

private Callable<Boolean> recordInserted() {
    return this::dataExists;
}

this::前缀表示recordInsterted是当前对象的方法。 我们也可以说someDao::dataExists 。 简单地将此语法turns方法放入我们可以传递的函数对象中（此过程在Scala中称为eta扩展 ）。 到目前为止，不再需要recordInsterted()方法，因此我可以内联它并将其完全删除：

await().atMost(10, SECONDS).until(this::dataExists);

我不确定我更喜欢什么-新的lambda语法或IntelliJ IDEA如何采用Java 8之前的代码并自动为我进行改版 （嗯，这仍然有点试验性，刚刚报道了IDEA-106670 ）。 我可以在IntelliJ项目级的Lambda中运行此意图，从而在几秒钟内启用整个代码库。 甜！

但是回到原来的问题。 通过提供体面的API和一些方便的功能，Awaitility很有帮助。 我将它与FluentLenium广泛结合使用。 但是定期轮询状态变化感觉有点像变通办法，并且仍然引入了最小的延迟。 但是请注意，在异步任务上运行和同步非常普遍，并且JDK已经提供了必要的功能： Future抽象 ！

java.util.concurrent.Future

为了限制重构的范围，我将暂时保留原始的new Thread()方法，并使用Guava中的SettableFuture<V> 。 它是Future<V>实现，允许在任何时间从任何线程触发完成或失败（请参阅DeferredResult – Spring MVC中的异步处理以获取更多高级用法）。 如您所见，更改非常小：

public class ThreadWrapper {
 
    public ListenableFuture<Void> doWork() {
        final SettableFuture<Void> future = SettableFuture.<Void>create();
 
        Thread thread = new Thread() {
 
            @Override
            public void run() {
                addDataToDB()
                //...
 
                //last instruction
                future.set(null);
            }
 
            private void addDataToDB() {
                // Dummy Code...
                // ...
 
            }
 
        };
 
        thread.start();
        return future;
    }
 
}

doWork()现在返回在异步任务内部控制生命周期的ListenableFuture<Void> 。 我们使用Void但实际上您可能想返回一些异步结果。 future.set(null)调用至关重要。 它表示将来已实现，并且将通知所有等待该将来的线程。 再一次，在实践中，您将使用例如Future<Integer> ，然后我们将说future.set(someInteger)而不是null 。 这里null只是Void类型的占位符。 这对我们有什么帮助？ 测试代码现在可以依赖将来的完成：

final ListenableFuture<Void> future = wrapper.doWork();
future.get(10, SECONDS);

future.get()阻塞，直到将来完成（超时），即直到我们调用future.set(...)为止。 顺便说一句，我使用的是Guava的ListenableFuture ，但是Java 8引入了等效和标准的CompletableFuture –我将很快写它。

所以，我们到了某个地方。 Future<T>是用于等待和发信号通知后台作业完成的有用抽象。 但也有一个巨大的优势， Future未服用，ekhm，从优势-异常处理和传播。 Future.get()将阻塞，直到Future.get()完成，并返回异步结果或引发最初从我们的工作中引发的异常。 这对于异步测试非常有用。 当前，如果Thread.run()引发异常，则它可能会记录也可能不会记录或对我们可见，并且将来将永远无法完成。 使用Awaitility会稍微好一些-它会超时而没有任何有意义的原因，必须在控制台/日志中手动进行跟踪。 但是，只需稍作修改，我们的测试就会更加冗长：

public void run() {
    try {
        addDataToDB()
        //...
        future.set(null);
    } catch (Exception e) {
        future.setException(e);
    }
}

如果异步作业中发生某些异常，它将弹出并显示为JUnit / TestNG失败原因。

（听）ExecutorService

而已。 如果addDataToDB()引发异常，它将不会丢失。 相反，测试中的future.get()将为我们重新抛出该异常。 我们的测试不会只是超时，也不会让我们知道发生了什么问题。 太好了，但是我们真的必须创建这个特殊的SettableFuture<T>实例，难道我们不能仅使用已经为我们提供Future<T>并具有正确基础实现的现有库吗？ 当然！ 这样就需要进一步重构：

import com.google.common.util.concurrent.ListeningExecutorService;
import com.google.common.util.concurrent.MoreExecutors;
 
import java.util.concurrent.Executors;
import java.util.concurrent.Future;
 
public class ThreadWrapper {
 
    private final ListeningExecutorService executorService =
        MoreExecutors.listeningDecorator(
            Executors.newSingleThreadExecutor()
        );
 
    public ListenableFuture<?> doWork() {
        Runnable job = new Runnable() {
            @Override
            public void run() {
                //...
            }
        };
        return executorService.submit(job);
    }
 
}

这就是你们一直在等待的东西。 不要一直启动新Thread ，请使用线程池！ 实际上，我通过使用ListeningExecutorService （对ExecutorService的扩展）返回了ListenableFuture实例（ 请参阅为什么 ListenableFuture ，进一步走了一步。 但是解决方案不需要这样做，我只是传播了良好的做法。 如您所见，现在已经为我们创建并管理了Future实例。 测试完全相同，但是生产代码更简洁，更可靠。

MoreExecutors.sameThreadExecutor（）

我想向您展示的最后一个技巧是依赖注入。 首先，让我们从ThreadWrapper类外部化线程池的创建：

private final ListeningExecutorService executorService;
 
public ThreadWrapper() {
    this(Executors.newSingleThreadExecutor());
}
 
public ThreadWrapper(ExecutorService executorService) {
    this.executorService =
        MoreExecutors.listeningDecorator(executorService);
}

现在，我们可以选择提供自定义ExecutorService 。 出于其他各种原因，这是件好事，但是对我们来说，这提供了全新的测试机会： MoreExecutors.sameThreadExecutor() 。 这次我们稍微修改一下测试：

final ThreadWrapper wrapper = new ThreadWrapper(MoreExecutors.sameThreadExecutor());
wrapper.doWork().get();

看看我们如何通过自定义ExecutorService ？ 这是一个非常特殊的实现，它实际上并不维护任何类型的线程池。 每次您向该“池” submit()某个任务时，它将以阻塞方式在同一线程中执行。 这意味着即使生产代码没有太大变化，我们也不再需要异步测试！ wrapper.doWork()将阻塞，直到“后台”作业完成。 仍然需要对get()额外的调用，以确保传播了异常，但是保证永远不会阻塞（因为作业已经完成）。

如果您某种程度上依赖于基于线程的属性（例如事务，安全性， ThreadLocal ，则使用同一线程而不是线程池来执行异步任务可能会产生意外结果。 但是，如果您将标准ThreadPoolExecutor与CallerRunsPolicy一起CallerRunsPolicy ，则在线程池溢出的情况下，JDK会以这种方式运行。 因此，这并不罕见。

摘要

测试异步代码很困难，但是您可以选择。 几种选择。 但是令我印象深刻的一个结论是我们努力的副作用。 我们重构了原始代码以使其可测试。 但是最终的生产代码不仅可以测试，而且结构和健壮性也更好。 令人惊讶的是，它甚至与以前的版本兼容，因为我们几乎没有将返回类型从void更改为Future<Void> 。

这似乎是一条规则-可测试的代码通常可以更好地设计和实现。 单元测试是使用我们库的第一个客户端代码。 这自然迫使我们要更多地考虑消费者，而不是实现。

参考：从Java和社区博客的JCG合作伙伴 Tomasz Nurkiewicz 重新审视了同步多线程集成测试 。

翻译自: https://www.javacodegeeks.com/2013/05/synchronising-multithreaded-integration-tests-revisited.html