单元测试要求
单独
测试单元。为了实现这一点，普遍的共识是使用
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，确保结果是预期的。