如何模拟调用同一类中存在的其他方法的方法

Question

我是 Mockito 的新手。我正在使用 Mockito 为一个类编写测试。我有一个调用同一类的其他方法的方法。我将如何嘲笑这种方法？我已经发布了我试图为其编写测试的课程。我正在尝试模拟方法 process(PersonDTO person)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    }}

Answer 1

首先，从技术上讲，您可以使用 mockito 从类中模拟选定的方法。此功能称为部分模拟。

第二：在某些情况下，在测试一个类以模拟来自同一类的其他方法时是有意义的。一个很好的例子是将与其他组件的交互捆绑在一起的方法（为了举例起见，我们称它为do_interactions），这样该类的其余方法就没有此类交互，并且仅为do_interactions该目的调用。更具体地说，考虑一种为其他方法传递文件内容的方法：它将与操作系统的交互（如打开和阅读）捆绑在一起，并只返回内容。然后，您可以通过模拟该函数使其在测试需要时返回“模拟”文件内容，从而轻松地执行与操作系统隔离的测试。

也就是说，有些例子表明这种嘲笑是有道理的，但这不一定适用于您的情况。

第三，测试是关于发现错误（参见 Myers、Badgett、Sandler：软件测试的艺术，或 Beizer：软件测试技术等），单元测试旨在发现那些可以在孤立代码中找到的错误. 为了有效地发现错误，您必须进行特定于实现的测试：错误在实现中，不同的实现有不同的错误。想一想大量的排序算法：它们都有相同的 API，但它们的实现却完全不同。或者，考虑实现 Fibonacci 函数的方法：作为迭代或递归函数，作为封闭形式的表达式 (Moivre/Binet)，或作为查找表。同样，界面始终相同，可能的错误差异很大，单元测试策略也是如此。和，单元测试是最接近实现级别的测试级别——集成测试、子系统测试和系统测试都在上升，因此不太适合在实现中查找错误。因此，尝试在单元测试中保持与实现无关可能会导致测试套件效率降低。

也就是说，您确实也应该努力降低测试维护工作量。这意味着，如果特定测试不需要特定的测试用例实现，则不要将其具体化。并且，对于那些有充分理由是特定于实现的测试，仍然尽量保持较低的维护工作量，例如通过在辅助方法中提取测试的特定于实现的部分，以减少您必须维护的测试代码量，以防万一SUT 的更改。