我有一个关于在junits中使用EasyMock的问题。我们为junits配置了一个框架,它使用内存derby数据库和EasyMock来测试我们的服务项目。我们完全在内存德比中使用dao层。问题出现在完全使用EasyMock或者在服务层中使用easymock和derby的天气。以下是场景:
//class under test is in user-service project
class ServiceClassUnderTest {
IUserService userService;
IAddressService addressService;
public Address getUsersAddress(String id) {
User user = userService.getUserById(id);
// some logic goes here
Address address = addressService.getAddresdByUser(user);
// some validations goes here
return address;
}
}
测试类位于用户服务项目中,IUserService接口也是如此。而IAddressService接口位于地址服务项目中,用作用户服务项目中的依赖项。
现在问题在于一些同事提出的改变方法。
为userService准备测试数据,因为它在同一个项目中,并且模拟地址服务作为依赖项目的一部分,我们可能对其行为和表结构不太了解
优点:更简洁的方法,因为我们有模拟和测试数据的最小代码在单独的sql文件中
模拟所有服务,无论它是在同一项目中还是在依赖项目的一部分
缺点:更多模拟相关代码,然后是实际测试相关代码,这使得难以维护和损害可读性。
给出的代码示例仅解释了在实际项目中我们在单个类中具有多个服务bean的更复杂结构的场景。
请您就哪种方法更好以及为什么考虑我为这两种方法提供的论据给出您的建议?
答案 0 :(得分:1)
如果没有完整的大局,权威就很难。假设你真的想要单元测试,我通常会这样做:
这"一切"应该不超过3或4个依赖项。否则,我将重构,直到我得到可读的东西。
拥有比生产代码更多的测试代码是正常的。
如果我在测试方法中最终得到了琐碎的代码,我就不会测试它。但是,测试也可用于记录。所以这是一个模糊的界限。