为什么避免使用Mockito.verify?

Question

我的公司不允许使用Mockito。在单元测试中验证。甚至有一个定制的声纳规则
规则如下
应该通过断言来验证结果，而不是使用“验证到执行”过程验证。因为如果我们验证流程，在流程更改后需要更多的努力来维护测试，但输入和输出保持不变。确保每一行代码都对结果有影响，并断言结果以证明逻辑正确
不合规代码示例

verify(graphics2D, times(1)).dispose();// Noncompliant

合规解决方案

assertThat(((SunGraphics2D) graphics2D).getSurfaceData()).isInstanceOf(NullSurfaceData.class);

对于数据库或中间件操作，断言使用嵌入式数据库或中间件成功写入数据。

对于restful请求，使用wiremock的verify断言模拟服务器收到了相应的请求

WireMock.verify(postRequestedFor(urlEqualTo("http://localhost:8080/query"))
                .withHeader("Content-Type", equalTo("application/json"))
                .withRequestBody(equalToJson("{" +
                        "\"testing-library\": \"WireMock\"," +
                        "\"creator\": \"Tom Akehurst\"," +
                        "\"website\": \"wiremock.org\"" +
                        "}")));

我的问题是，是否有其他IT公司有类似的规则来避免使用Mockito。在单元测试中验证？这是一个好规则还是一个坏规则？非常感谢你。

Answer 1

没有验证的断言只能在测试方法返回后检查结束状态。为了有一个完整的结束状态，你需要有所有的真实对象，没有模拟。使用的任何模拟都意味着您最终没有完整的状态，并且如果不使用验证，您无法检查应该检查的所有内容。所以，如果禁止使用验证，那么你根本不应该使用Mockito。您应该意识到您正在编写集成测试而不是单元测试。

但是，集成测试不会告诉您出了什么问题，以及在哪里查找根本原因：错误是在您的代码中还是在您正在使用的第三方库的代码中？你必须自己调查和调试才能找到答案。这就是为什么你需要真正的单元测试。

如果被测试的方法需要进行单元测试，这意味着测试应该测试该方法正在做什么，而不依赖于所调用的任何方法的实现。当被调用的方法在模拟中时，发送到模拟的数据通常不在任何位置，并且您无法验证调用中是否传递了正确的数据。您可以使用一个存储参数的应答对象来存根该方法，并在之后断言它们。但是，您只是在使用断言实现自己的验证方法。当调用的方法不是模拟方法时，测试将取决于该方法的实现，不再是单元测试。更改被调用方法的实现可能会中断许多调用该方法的方法的单元测试。

或者简而言之：如果你的公司不想让你使用验证，他们不想让你写单元测试，而是集成测试。

单元测试和集成测试都是有用的，它们相互补充。如果结构良好，两者都是可维护的。但是当您混合使用这两种类型（使用真实对象而不是模拟的单元测试或使用模拟的集成测试）时，测试变得难以维护。因此，对于集成测试，避免验证（和模拟）是一条好规则。对于单元测试来说，这是一个糟糕的规则，因为它使编写真正的单元测试变得不可能。

Answer 2

嗯，这需要一个很长的答案，但我会尽量简短。换公司。这基本上是两种不同的o型测试。在一种情况下，您正在检查输入和输出（assert），在另一种情况下，您的输出很可能是无效的，然后您只需验证函数是否被调用。

除此之外，您还可以在“集成测试”中使用verify，其中您希望验证函数是否被调用，还可能希望验证使用“inoder（）”调用函数的顺序，如下所述：Mockito验证方法调用的顺序/顺序

有时单元测试和集成测试重叠。集成测试有2个子类型：

• 因必要而需要模仿的；
• 那些根本不使用模拟的人。

最近使用了一个maven插件，它允许在测试或验证阶段随意生成docker容器。

<groupId>io.fabric8</groupId>
<artifactId>docker-maven-plugin</artifactId>
<version>0.33.0</version>

这允许您在项目中的公共Jenkins管道中运行集成测试和端到端测试。唯一的问题出现在当您不能在Jenkins中使用docker时，因为docker没有安装在运行测试的机器上。