建视频网站的费用,网站安全检测中的安全事件监测包含哪些监控指标,没有网站怎么做链接视频教程,vps建设网站我最近在Captain Debug的Blog上偶然发现了一篇文章“ 同步多线程集成测试 ”。 该文章强调了设计涉及被测类以异步方式运行业务逻辑的集成测试的问题。 给出了这个人为的示例#xff08;我删除了一些评论#xff09;#xff1a; public class ThreadWrapper {public void d… 我最近在Captain Debug的Blog上偶然发现了一篇文章“ 同步多线程集成测试 ”。 该文章强调了设计涉及被测类以异步方式运行业务逻辑的集成测试的问题。 给出了这个人为的示例我删除了一些评论 public class ThreadWrapper {public void doWork() {Thread thread new Thread() {Overridepublic 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 CallableBoolean recordInserted() {return new CallableBoolean() {Overridepublic Boolean call() throws Exception {return dataExists();}};
} 我认为这里没有什么可解释的。 dataExists()只是一个boolean方法最初返回false但一旦后台任务 addDataToDB() 完成最终将返回true 。 换句话说我们假设后台任务引入了一些副作用而dataExists()可以检测到该副作用。 顺便说一句我碰巧安装了具有Lambda支持的JDK 8而IntelliJ IDEA给了我这个很好的工具提示 突然我得到了建议的与Java 8兼容的替代方案 private CallableBoolean recordInserted() {return () - dataExists();
} 但是还有更多 将我的代码转换为 private CallableBoolean 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中的SettableFutureV 。 它是FutureV实现允许在任何时间从任何线程触发完成或失败请参阅DeferredResult – Spring MVC中的异步处理以获取更多高级用法。 如您所见更改非常小 public class ThreadWrapper {public ListenableFutureVoid doWork() {final SettableFutureVoid future SettableFuture.Voidcreate();Thread thread new Thread() {Overridepublic void run() {addDataToDB()//...//last instructionfuture.set(null);}private void addDataToDB() {// Dummy Code...// ...}};thread.start();return future;}} doWork()现在返回在异步任务内部控制生命周期的ListenableFutureVoid 。 我们使用Void但实际上您可能想返回一些异步结果。 future.set(null)调用至关重要。 它表示将来已实现并且将通知所有等待该将来的线程。 再一次在实践中您将使用例如FutureInteger 然后我们将说future.set(someInteger)而不是null 。 这里null只是Void类型的占位符。 这对我们有什么帮助 测试代码现在可以依赖将来的完成 final ListenableFutureVoid future wrapper.doWork();
future.get(10, SECONDS); future.get()阻塞直到将来完成超时即直到我们调用future.set(...)为止。 顺便说一句我使用的是Guava的ListenableFuture 但是Java 8引入了等效和标准的CompletableFuture –我将很快写它。 所以我们到了某个地方。 FutureT是用于等待和发信号通知后台作业完成的有用抽象。 但也有一个巨大的优势 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()将为我们重新抛出该异常。 我们的测试不会只是超时也不会让我们知道发生了什么问题。 太好了但是我们真的必须创建这个特殊的SettableFutureT实例难道我们不能仅使用已经为我们提供FutureT并具有正确基础实现的现有库吗 当然 这样就需要进一步重构 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() {Overridepublic 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更改为FutureVoid 。 这似乎是一条规则-可测试的代码通常可以更好地设计和实现。 单元测试是使用我们库的第一个客户端代码。 这自然迫使我们要更多地考虑消费者而不是实现。 参考从Java和社区博客的JCG合作伙伴 Tomasz Nurkiewicz 重新审视了同步多线程集成测试 。 翻译自: https://www.javacodegeeks.com/2013/05/synchronising-multithreaded-integration-tests-revisited.html
