使用 EasyMock 很好地实现单元测试答案

【问题标题】：Good implementation of unit test with EasyMock使用 EasyMock 很好地实现单元测试
【发布时间】：2015-08-21 15:21:30
【问题描述】：

我有一个关于使用 EasyMock 实现单元测试的问题。

第一次实现：

Capture<String> capturedString = newCapture();
myService.doSomething(capture(capturedString));
expectLastCall();

assertEquals("stringValue", catpuredString.getValue());

第二次实施：

myService.doSomething("stringValue");
expectLastCall();

我对第一个实现感到满意，因为存在断言。但在第二个实现中，我希望将“stringValue”传递给我的服务。如果不是这种情况，EasyMock 将抛出异常。那么这两种实现之间有区别吗？如果不是，一个比另一个好吗？

谢谢。

【问题讨论】：

标签： java unit-testing easymock

【解决方案1】：

GreenGiant 的回答非常好。两种方式在结果上是相同的，但有不同的感觉。顺便说一句，无需添加expectLastCall()。它隐含在 void 方法中。

补充答案：

期望是您期望发生的事情。你关心的东西。例如，如果您关心 doSomething 被调用但您不关心传递的参数，您将使用 any() 作为匹配器。表明你的意图（你不在乎）。如果参数确实重要，则等于匹配器有意义。

然后，确实经常使用捕获，因为您不太确定将传递什么。例如，如果对象上没有定义equals() 方法。

当我有复杂的对象要检查时，我倾向于使用捕获和断言列表。如果我有一个包含许多字段的 bean，那么拥有一个断言列表比使用 cmpEq 匹配器更容易。

那么这种方法唯一的缺点是你不会马上知道传递的参数是无效的。测试的方法将继续执行，之后可能会失败。所以你永远不会达到你的断言并认为代码中的错误比实际情况更远。

但是被测试的代码是很好的原子并且不是太复杂，这不应该发生太多。

【讨论】：

【解决方案2】：

我想这取决于您在录制模拟呼叫之前是否预先知道字符串值。

如果您已经知道字符串值，请使用第二种实现，因为它更简单。
但如果您不提前知道，请使用第一个实现。例如，如果传递给您的服务的值是动态的，并且您在实际运行测试之前不知道它应该是什么。

【讨论】：