使用 Mockito 的 Capture 改进您的测试

一则或许对你有用的小广告

欢迎加入小哈的星球 ,你将获得:专属的项目实战 / Java 学习路线 / 一对一提问 / 学习打卡/ 赠书活动

目前,正在 星球 内带小伙伴们做第一个项目:全栈前后端分离博客项目,采用技术栈 Spring Boot + Mybatis Plus + Vue 3.x + Vite 4手把手,前端 + 后端全栈开发,从 0 到 1 讲解每个功能点开发步骤,1v1 答疑,陪伴式直到项目上线,目前已更新了 204 小节,累计 32w+ 字,讲解图:1416 张,还在持续爆肝中,后续还会上新更多项目,目标是将 Java 领域典型的项目都整上,如秒杀系统、在线商城、IM 即时通讯、权限管理等等,已有 870+ 小伙伴加入,欢迎点击围观

单元测试要求 单独 测试单元。为了实现这一点,普遍的共识是使用 DI 以解耦的方式设计我们的类。在这个范式中,无论是否使用框架,无论使用编译时还是运行时编译,对象实例化都是专用工厂的职责。特别是,这意味着 new 关键字应该只在那些工厂中使用。

然而,有时,拥有专门的工厂并不合适。将窄范围实例注入更宽范围实例时就是这种情况。我最近偶然发现的一个用例涉及事件总线,代码如下:

 public class Sample { private EventBus eventBus; public Sample(EventBus eventBus) { this.eventBus = eventBus; } public void done() { Result result = computeResult() eventBus.post(new DoneEvent(result)); } private Result computeResult() { ... } }

使用运行时 DI 框架——例如 Spring 框架,如果 DoneEvent 没有参数,这可以更改为查找方法模式。

 public void done() { eventBus.post(getDoneEvent()); } public abstract DoneEvent getDoneEvent();

不幸的是,这个论点只是阻止我们使用这个巧妙的技巧。无论如何,它不能通过运行时注入来完成。不过,这并不意味着不应该测试 done() 方法。问题不仅在于如何断言调用该方法时,总线中会发布一个新的 DoneEvent ,还要检查包装的结果。

有经验的软件工程师可能知道 Mockito.any(Class) 方法。这可以这样使用:

 public void doneShouldPostDoneEvent() { EventBus eventBus = Mockito.mock(EventBus.class); Sample sample = new Sample(eventBus); sample.done(); Mockito.verify(eventBus).post(Mockito.any(DoneEvent.class)); }

在这种情况下,我们确保将正确类型的事件发布到队列中,但我们不确定结果是什么。如果结果无法断言,代码的可信度就会降低。 Mockito 来救援。 Mockito 提供捕获,就像参数的占位符一样。上面的代码可以这样改:

 public void doneShouldPostDoneEventWithExpectedResult() { ArgumentCaptor<DoneEvent> captor = ArgumentCaptor.forClass(DoneEvent.class); EventBus eventBus = Mockito.mock(EventBus.class); Sample sample = new Sample(eventBus); sample.done(); Mockito.verify(eventBus).post(captor.capture()); DoneEvent event = captor.getCapture(); assertThat(event.getResult(), is(expectedResult)); }

在第 2 行,我们创建了一个新的 ArgumentCaptor。在第 6 行,我们用 captor.capture() 替换了 any() 用法,技巧就完成了。结果随后由 Mockito 捕获,并可通过第 7 行的 captor.getCapture() 获得。最后一行——使用 Hamcrest,确保结果是预期的。