MockMvc 与端到端测试

MockMvc 建立在来自 infra-test 模块的 Servlet API mock 实现之上，不依赖于运行的容器。因此，与具有实际客户端和实时运行服务器的完整端到端集成测试相比，存在一些差异。

思考这个问题的最简单方法是从一个空白的 HttpMockRequestImpl 开始。你向其中添加的任何内容就是请求变成的样子。可能会让你感到惊讶的事情是，默认情况下没有上下文路径；没有 jsessionid cookie；没有转发、错误或异步分派；因此，没有实际的 JSP 渲染。相反，“forwarded”和“redirected”URL 保存在 MockHttpResponseImpl 中，并可以通过期望进行断言。

这意味着，如果你使用 JSP，你可以验证请求转发到的 JSP 页面，但不会渲染任何 HTML。换句话说，JSP 不会被调用。但是请注意，所有其他不依赖于转发的渲染技术，例如 Thymeleaf 和 Freemarker，都会按预期将 HTML 渲染到响应体中。通过 @ResponseBody 方法渲染 JSON、XML 和其他格式也是如此。

或者，你可以考虑 Infra App 提供的带有 @InfraBootTest 的完整端到端集成测试支持。请参阅 Infra App 参考指南。

每种方法都有利弊。Web MVC Test 中提供的选项是从经典单元测试到完整集成测试的不同阶段。可以肯定的是，Web MVC Test 中的任何选项都不属于经典单元测试的范畴，但它们稍微接近一些。例如，你可以通过将 mock 服务注入控制器来隔离 Web 层，在这种情况下，你仅通过 MockDispatcherHandler 但使用实际的 Infra 配置来测试 Web 层，就像你可以将数据访问层与上层隔离进行测试一样。此外，你可以使用独立设置，一次专注于一个控制器，并手动提供使其工作所需的配置。

使用 Web MVC Test 时的另一个重要区别是，从概念上讲，此类测试是服务器端的，因此你可以检查使用了哪个处理程序、是否使用 HandlerExceptionResolver 处理了异常、模型的内容是什么、有哪些绑定错误以及其他细节。这意味着编写期望更容易，因为服务器不是一个不透明的盒子，而在通过实际 HTTP 客户端进行测试时它是。这通常是经典单元测试的一个优点：它更容易编写、推理和调试，但不能取代对完整集成测试的需求。同时，重要的是不要忽略响应是要检查的最重要的事情这一事实。简而言之，即使在同一个项目中，这里也有多种测试风格和策略的空间。