java - 是否不需要验证与 Mockito 中模拟的方法相同的方法？

Question

我经常看到验证的方法与 Mockito 中模拟的方法相同(如下例)。在这些情况下调用 Mockito.verify() 有什么额外的好处吗？

//mock method
FooService fs = mock(FooService.class);
when(fs.getFoo()).thenReturn("foo");

//method under test
fs.doSomething();

//verify method
verify(fs).getFoo();

如果未调用 fs.getFoo()，该方法将失败。那么为什么要调用verify呢？如果您需要在验证中使用 ArgumentCaptor 断言参数，我看到了好处；除了 ArgumentCaptor 案例之外，是否只是不必要的？

Answer 1

Mockito 文档反复说它通常是多余的。这在 verify(T)'s Javadoc 中逐字出现作为 Mockito's main class Javadoc section 2 中代码块中的多个单行注释:

Although it is possible to verify a stubbed invocation, usually it's just redundant.If your code cares what get(0) returns, then something else breaks (often even before verify() gets executed).If your code doesn't care what get(0) returns, then it should not be stubbed. Not convinced? See here.

请注意，最初链接的文章“Asking and Telling”是由 Mockito 创始人 Szczepan Faber 撰写的，可以认为是 Mockito 设计中的权威文档。摘自该帖子:

Do I really have to repeat the same expression? After all, stubbed interactions are verified implicitly. The execution flow of my own code does it completely for free. Aaron Jensen also noticed that:

If you’re verifying you don’t need to stub unless of course that method returns something that is critical to the flow of your test (or code), in which case you don’t really need to verify, because the flow would have verified.

简单回顾一下:没有重复的代码。

但是，如果一个有趣的交互具有询问和讲述的特征怎么办？我是否必须在 stub() 和 verify() 中重复交互？我最终会得到重复的代码吗？并不真地。在实践中:如果我 stub ，那么它是免费验证的，所以我不验证。 如果我验证，那么我不关心返回值，所以我不 stub 。无论哪种方式，I don’t repeat myself .不过从理论上讲，我可以想象一种罕见的情况，我确实验证了 stub 交互，例如确保 stub 交互恰好发生了 n 次。但这是行为的另一个方面，显然是一个有趣的方面。因此，我想说清楚一点，我非常乐意牺牲一行额外的代码……

最近版本的 Mockito(自发布此问答以来发布)添加了一些额外的功能 allow或 default to更严格的 mock 风格。尽管如此，普遍的期望是通过仅验证您无法通过断言或成功完成测试确认的内容来避免脆弱性。

总的来说，Mockito 的设计是让测试尽可能灵活，编码不是针对实现，而是针对您正在测试的方法的规范。尽管您偶尔会看到方法调用作为函数规范的一部分(“向服务器提交 RPC”或“立即调用传递的 LoginCallback”)，但您更有可能希望验证可以执行的后置条件从 stub 中推断:检查 getFoo 是否被调用并不是规范的一部分，只要您 stub getFoo 返回“foo”并且数据存储包含一个其相应属性设置为“foo”的单个对象。

---

简而言之，仅显式验证无法从精心设计的 stub 和后置条件断言中隐含的交互被认为是良好的 Mockito 风格。它们可能是对其他方面无法衡量的副作用(记录代码、线程执行器、ArgumentCaptors、多方法调用、回调函数)的良好调用，但通常不应应用于 stub 交互。