|
对于最新的稳定版本，请使用 Spring Framework 7.0.6! |
MockMvc与端到端测试
MockMvc 是基于来自
spring-test 模块的 Servlet API 模拟实现构建的，并不依赖于运行中的容器。因此，与使用实际客户端和运行中的服务器进行完整的端到端集成测试相比，存在一些差异。
最简单的方法是从一个空白的MockHttpServletRequest开始。
无论你向它添加什么，请求就会变成什么。可能会让你感到意外的是，默认情况下没有上下文路径；没有jsessionid cookie；没有转发、错误或异步调度；因此，也没有实际的JSP渲染。相反，
“转发”和“重定向”的URL会保存在MockHttpServletResponse中，并可以通过预期断言进行验证。
这意味着，如果你使用JSP，你可以验证请求被转发到的JSP页面，但不会渲染任何HTML。换句话说，JSP没有被调用。然而，请注意，所有其他不依赖转发的渲染技术，如Thymeleaf和Freemarker，都会如预期地将HTML渲染到响应体中。同样地，通过@ResponseBody方法渲染JSON、XML和其他格式也是如此。
Alternatively, you may consider the full end-to-end integration testing support from
Spring Boot with @SpringBootTest. See the
Spring Boot Reference Guide.
每种方法都有其优缺点。Spring MVC Test 提供的选项在经典单元测试和完整集成测试之间有所不同。可以肯定的是，Spring MVC Test 中的任何选项都不属于经典单元测试的范畴，但它们离经典单元测试更近一些。例如，你可以通过向控制器注入模拟服务来隔离 web 层，在这种情况下，你只通过 DispatcherServlet 测试 web 层，但使用实际的 Spring 配置，就像你可能会隔离地测试数据访问层一样。此外，你可以使用独立设置，一次专注于一个控制器，并手动提供使其正常工作的所需配置。
使用Spring MVC Test时，另一个重要的区别是，从概念上讲，这些测试是在服务器端进行的，因此你可以检查使用了哪个处理器，是否通过HandlerExceptionResolver处理了异常，模型的内容是什么，有哪些绑定错误，以及其他细节。这意味着编写预期结果更容易，因为服务器不再是通过实际HTTP客户端进行测试时的黑盒。这通常是经典单元测试的一个优势：编写、推理和调试都更容易，但并不能取代全面集成测试的需求。同时，重要的是不要忽视检查响应的重要性。简而言之，在同一个项目中可以采用多种测试风格和策略。