我是Mockito的新手。我正在使用Mockito为类编写测试。我有一个方法可以调用同一类的其他方法。我将如何模拟这种方法?我已经发布了我要为其编写测试的类。我正在尝试模拟方法过程(PersonDTO人员)
public class Processor {
@Autowired
private SomeService service;
@Autowired
private SomeServiceProperties properties;
private Util util = new Util();
public SPMOutboundVO process(PersonDTO person) throws Exception {
SPMOutboundVO outboundVO = null;
if(validatePersonForBenefitsProcessing(person)) {
PersonPayrollFromWorkdayVO personPayrollFromWorkdayVO = service.getPersonPayrollFromWorkday(util.getStartOrEndDate(DayOfWeek.SUNDAY),util.getStartOrEndDate(DayOfWeek.SATURDAY),person.getEmployeeID());
if(personPayrollFromWorkdayVO != null) {
person.setBillingStartDate(getPayrollPeriod(personPayrollFromWorkdayVO));
person.setAmount(util.getMonthlyDiscountPayRate(person.getPayPeriod(),getDiscountRate(personPayrollFromWorkdayVO)));
}
if(isNewLeave(person,getPayrollPeriod(personPayrollFromWorkdayVO))) {
person.setBillingStartDate(getPayrollPeriod(personPayrollFromWorkdayVO));
outboundVO = processOutboundSPMInsertRecords(person);
} else if (person.isReturnFromLeaveOrTermed()){
person.setBillingEndDate(person.getFirstDayBackAtWorkMinus1());
outboundVO = processOutboundSPMUpdateRecords(person);
}
}
return outboundVO;
}
public boolean validatePersonForBenefitsProcessing(PersonDTO person) {
// Some code
}
public SPMOutboundVO processOutboundSPMInsertRecords(PersonDTO person) {
// Some code
}
public SPMOutboundVO processOutboundSPMUpdateRecords(PersonDTO person) {
// Some code
}
public String getPayrollPeriod(PersonPayrollFromWorkdayVO personPayrollFromWorkdayVO) {
// Some code
}
public boolean isNewLeave(PersonDTO, String) {
// Some code
}
}
答案 0 :(得分:0)
首先,从技术上讲,您可以使用Mockito模拟类中的选定方法。此功能称为部分模拟。在模仿文档中进行了解释:https://static.javadoc.io/org.mockito/mockito-core/3.0.0/org/mockito/Mockito.html#partial_mocks。
第二个:在某些情况下,测试一个类以模拟该类中的其他方法是有意义的。一个很好的例子是将与其他组件的交互捆绑在一起的方法(为方便起见,我们将其称为do_interactions
),这样该类的其余方法就没有此类交互,而仅调用do_interactions
为了这个目的。更具体地讲,考虑一种为其他方法传递文件内容的方法:它将诸如打开和读取之类的与操作系统的交互捆绑在一起,只返回内容。然后,您可以通过模拟该函数以使其在测试需要时返回“模拟”文件内容来轻松地独立于操作系统执行测试。
也就是说,在某些例子中,这种嘲笑是有意义的,但这不一定适用于您的情况。
第三,测试与发现错误有关(请参阅Myers,Badgett,Sandler:软件测试的艺术,或Beizer:软件测试技术等),单元测试旨在发现可以在以下位置发现的错误:孤立的代码。为了有效地发现错误,您将必须进行特定于实现的测试:错误存在于实现中,不同的实现具有不同的错误。考虑一下大量的排序算法:它们都具有相同的API,但是其实现却完全不同。或者,考虑实现Fibonacci函数的方式:作为迭代或递归函数,作为闭合形式的表达式(Moivre / Binet)或作为查找表。同样,界面始终是相同的,可能的错误有很大的不同,因此单元测试策略也是如此。而且,单元测试是最接近实现级别的测试级别-集成测试,子系统测试和系统测试正在逐步提高,因此不太适合在实现中查找错误。因此,尝试在单元测试中保持与实现不可知的关系可能会导致测试套件效率降低。
也就是说,您也应该努力降低测试维护的工作量。这意味着,如果不需要特定的测试用例实现,则不要将其特定化。而且,对于那些出于特定原因特定于实现的测试,仍应尝试降低维护工作量,例如通过在辅助方法中提取测试的实现特定部分,以减少必须维护的测试代码量SUT的更改(请参阅[{Meszaros: Principles of Test Automation: Ensure Commensurate Effort])。