单元测试断言vs Mockito。验证（）

Question

玩弄Mockito来实现我的服务的单元测试，但由于某种原因，我无法通过我的厚脑袋来实现这一点。我的考试通过了，但我不能确信我做得对。

下面是一个测试count（）方法的示例。该方法只是将调用转发到它的存储库，我不想验证仅此而已，没有其他事情发生。这就是我得到的：

@RunWith(MockitoJUnitRunner.class)
public class PersonServiceImplTest {

    @Mock
    private PersonRepository personRepository;

    @InjectMocks
    private PersonServiceImpl personService;

    @Test
    public void testCount() {

        when(personRepository.count()).thenReturn(2L);

        long count = personService.count();

        assertEquals(2L, count);

        verify(personRepository).count();
    }
}

我的考试及格了，但我有一些问题。

>

我需要验证吗？我觉得我这样做是因为我想验证personRepository。实际上调用了count（）。或者当我也有assertEquals（）时，这是多余的吗？

我是否需要assertEquals和verify？

最后，我做得对吗：）

谢谢你

Answer 1

最好通过构造函数注入PersonRepository，而不是@InjectMocks。这也消除了对特定运行程序的需要（或者，在稍后的测试中，涉及Spring的低级测试）。

你对Mockito的使用是正确的，但不是最佳的。您确实需要assertEquals，因为您正在测试的是服务返回的值与您从存储库提供的值相同。验证...计数不是必需的，因为它通过检查是否返回了适当的值来暗示。您可以通过返回随机数而不是2来改进这一点。

还要检查是否真的值得在另一个对象中包装count（），或者是否只是添加了不必要的层。

最后，您可以考虑检查Spock；它是JUnit之上的一种基于Groovy的测试语言，提供了一种干净而强大的模拟语言。

Answer 2

整齐：

>

是需要的assertEquals（）：这取决于。在返回之前，是否对人员服务中的人员Repository.count（）的结果进行了任何操作，从而有可能更改其值？如果答案是肯定不是，那么您可能不需要assertEquals（）-但是如果有任何可能出错，那么assertEquals（）将确保它没有出错。

是否需要验证（）：视情况而定。有没有可能personRepository。count（）是否未调用？或者它被多次调用（verify（）默认情况下期望其参数只被调用一次）？如果没有，那么您可能不需要它。

你两者都需要吗：这取决于（注意到一种模式？）。见上文：他们做不同的事情。在许多情况下，你希望这两件事都被检查： 1.返回正确的结果，2.通过做你期望做的事情来返回结果。

你这样做对吗：嗯...看情况。是否人Repository.count（）看起来像

public int count() {
    return this.personService.count();
}

如果是这样，您可能根本不需要进行太多测试。如果您坚持要进行测试，跳过verify（）可能没问题，因为上面的方法除了调用您将要执行的verify函数之外，没有其他方法可以获取值，并且它会返回该值，因此很难多次调用它。

另一方面，如果函数如下所示：

public int count() {
    // get a personService from an injector
    // log the personService's details
    // generate a random number
    // try calling count() on personService, catch an error
    // if you caught the error, return the random number
}

然后，您可能确实想verify（），因为突然之间，发生了很多事情，其中一些事情（即随机数）可能会被混淆，无法正确运行，即使某些事情发生了可怕的错误。

Answer 3

是的，你做得对。

您正在将一个模拟存储库注入到一个真正的服务中，然后测试该服务。当涉及到服务中的业务逻辑时，任何事情都可能发生。这就是为什么用已知的输入和输出验证代码很重要，就像您正在做的那样。

>

根据存储库的响应，您正在检查业务逻辑的结果。这段代码相当简单，但是想象一下，如果业务逻辑提供的是平均值或总和，而不仅仅是存储库提供的相同值。

三,。verify和assertEquals正在测试不同的东西。verify检查是否调用了存储库方法，assert检查服务是否使用正确的值响应。假设您的服务方法有一个硬编码的返回2L。assertEquals将通过，但验证将失败。

是的，你做得对。您测试的内容与您测试的原因有关。是否需要特定的断言或验证通常取决于具体情况。在这种情况下，测试存储库方法是否返回2L，没有什么意义，但测试服务是否返回2L是一个很好的例子。类似地，测试服务方法是否已被调用也没有意义，但测试存储库方法是否已被调用是一个很好的例子。

现在您有了测试服务的工具，下一步是确定要编写哪些测试。