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

我有一个关于EasyMock很好地实现单元测试的问题

第一次实施：

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

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

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

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

---

谢谢。

我想这取决于你在录制模拟通话之前是否预先知道字符串值

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

---

绿巨人的回答很好。这两种方法在结果上是相同的，但有不同的感觉。顺便说一句，不需要添加

expectLastCall（）

。它在void方法中是隐式的

要补充回答：

期望是你期望发生的事情。你关心的事情。例如，如果您关心doSomething的调用，但不关心传递的参数，则可以使用

any（）

作为匹配器。表明你的意图（你不在乎）。如果参数确实重要，那么equals匹配器就有意义

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

equals（）

方法

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

cmpEq

matcher更容易

这种方法的唯一缺点是，您不会马上知道传递的参数无效。被测试的方法将继续执行，之后可能会失败。因此，您永远不会得出您的断言，并且认为错误在代码中的位置比实际位置更远

但是，如果测试的代码是很好的原子性并且不太复杂，那么这种情况不应该发生太多