Don't mock types you don't own

Question

这是我的代码：

import java.net.URI;
import javax.ws.rs.core.UriInfo;
(...)

    UriInfo mockUriInfo;
    String url = "test";

    mockUriInfo = mock(UriInfo.class);
    when(mockUriInfo.getRequestUri()).then(new URI(url));

不幸的是我遇到了错误：

then(org.mockito.stubbing.Answer) cannot be applied to (java.new URI)

我知道如何解决它？

Answer 1

你需要使用thenReturn而不是：

when(mockUriInfo.getRequestUri()).thenReturn(new URI(url));

如果您想使用then（这是thenAnswer的同义词，您需要将答案作为参数传递：

when(mockUriInfo.getRequestUri()).then(new Answer<Integer>() {
    public URI answer(InvocationOnMock invocation) throws Throwable {
        return new URI(url);
    }
}

Answer 2

Don't mock types you don't own

99％的时间真的是错的。相反，最好使用真实对象或使用集成测试（使用RESTAssured或其他东西）。

在mockito wiki上：Don't mock types you don't own !

这不是一个强硬路线，但越过这条线可能会产生影响！（很有可能。）


想象一下嘲笑第三方lib的代码。在第三个库的特定升级之后，逻辑可能会改变一点，但测试套件将执行得很好，因为它被嘲笑。所以稍后，认为一切都很好，毕竟构建墙是绿色的，软件已经部署并且...... Boom

这可能表示当前设计与第三方库没有足够的分离。

另一个问题是第三方lib可能很复杂，需要很多模拟才能正常工作。这会导致过度指定的测试和复杂的固定装置，这本身就会损害紧凑和可读目标。或者由于模拟外部系统的复杂性而导致的测试不足以覆盖代码。

相反，最常见的方法是围绕外部lib /系统创建包装器，尽管应该意识到抽象泄漏的风险，其中过多的低级API，概念或异常超出了包装器的边界。为了验证与第三方库的集成，编写集成测试，并使它们尽可能紧凑和可读。

如何正确模拟UriInfo？

2 个答案:

Don't mock types you don't own