|
此版本仍在开发中，尚未稳定。如需最新的稳定版本，请使用 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测试中提供的选项位于从经典单元测试到完全集成测试这一范围的不同阶段。可以肯定的是，Spring MVC测试中的任何选项都不属于经典单元测试的范畴，但它们更接近一些。例如，您可以通过向控制器注入模拟服务来隔离Web层，这样就可以只通过DispatcherServlet来测试Web层，但使用实际的Spring配置，就像您可能从其上方层独立测试数据访问层一样。此外，您可以使用独立设置，一次专注于一个控制器，并手动提供使其工作所需的配置。
在使用Spring MVC测试时，另一个重要的区别是，从概念上讲，这类测试是服务器端测试，因此您可以检查使用了哪个处理器、异常是否被HandlerExceptionResolver处理、模型的内容是什么、存在哪些绑定错误以及其他详细信息。这意味着编写预期更为简单，因为服务器不是一个不透明的盒子，就像通过实际HTTP客户端进行测试时那样。这通常是经典单元测试的一个优势：编写、理解和调试更容易，但不能替代全面集成测试的需求。同时，重要的是不要忽视响应是最需要检查的部分这一事实。简而言之，即使在同一项目中，也有多样化的测试风格和策略的空间。