【问题标题】:What is the point of making a test for Pageable?对 Pageable 进行测试有什么意义?
【发布时间】:2020-09-21 00:48:43
【问题描述】:

我应该用 Mockito 为这个方法写一个测试:

public Optional<Page<User>> getAllByPage(Integer pageSize, Integer page) {
    Pageable pageable = PageRequest.of(page, pageSize);
    return userRepository.findAll(pageable);
}

我很长时间无法理解,应该测试什么?测试 Pageable 有什么意义,此方法返回所有用户,所以我应该检查该方法是否返回所有用户?我在逻辑的某个地方犯了错误吗?

【问题讨论】:

    标签: java spring-boot hibernate jpa junit


    【解决方案1】:

    恐怕这几乎是基于意见的。

    问题是您正在查看实现。如果您有 IDE,请使用代码折叠来仅查看方法签名。那么,看看这个方法的要求是什么。

    现在,您可以对其进行测试。只需编写代码来检查方法是否符合要求(如果特定的输入参数产生所需的输出,非法参数会发生什么)。你完成了。稍后有人可以更改该方法的实现方式。如果测试仍然有效,那么您肯定没有人通过更改实现来破坏任何东西。

    因此,理想情况下,您将提供一个已实现部分所需行为的模拟存储库,以便在使用 Pageable 查询时返回您想要的数据。

    这样您就可以对返回的数据进行断言,并且您的测试是可靠的 - 即,如果有人更改了另一个实现,但它仍然产生所需的输出,那么您的测试就通过了。

    将其与调用 verify 进行比较。这个测试很脆弱,因为在改变实现时它会失败。为什么要呢?哪个业务需求被破坏导致测试失败?好吧,没有。

    如果您有一个测试套件来证明您的模拟数据层的行为方式与真实数据层的行为方式相同(达到所需的水平),那么您可以进行非常快速的伪集成测试,可以在真实数据层之前轻松运行那些。而且您正在以与实现无关的方式测试真实的东西、功能。

    【讨论】:

      【解决方案2】:

      您应该只对您实现的代码进行单元测试。由于在那种几乎没有的方法中,我不会对其进行单元测试。但我会确保集成和系统测试在所有可能的迭代中都涵盖该方法,以增加我对它的信任。

      另外,假设您提供了错误的页面大小或页码?会发生什么?不测能知道吗?

      【讨论】:

        猜你喜欢
        • 2010-09-29
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 2017-12-16
        • 2010-11-09
        • 1970-01-01
        • 2011-10-23
        • 2012-06-24
        相关资源
        最近更新 更多