使用EasyMock进行单元测试的良好实施

我对使用EasyMock进行单元测试的良好实现有疑问。使用EasyMock进行单元测试的良好实施

先执行：

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

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

第二个执行：

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

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

谢谢。

来源

2015-08-21 cheb1k4

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

要添加到答案：

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

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

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

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

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

来源

2015-08-22 02:12:11 Henri

我想这只是取决于你是否知道字符串值预先记录你的模拟电话。

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

来源

2015-08-21 17:42:04 GreenGiant

使用EasyMock进行单元测试的良好实施

回答

相关问题