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

Question

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

第一次实施：

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

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

第二次实施：

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

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

谢谢。

Answer 1

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

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

Answer 2

GreenGiant 的回答很好。两种方式在结果上是等价的，但有不同的感觉。顺便说一句，没有必要添加 expectLastCall()。它隐含在 void 方法中。

添加到答案中：

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

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

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

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

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

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

Good implementation of unit test with EasyMock

java

unit-testing

easymock