|
此版本仍在开发中，尚不被认为是稳定的。对于最新的稳定版本，请使用 Spring Framework 6.2.10！ |
MockMvc 与端到端测试
MockMvc 建立在 Servlet API 模拟实现之上，来自spring-test模块，并且不依赖于正在运行的容器。因此，存在与实际客户端和实时服务器运行的完整端到端集成测试相比，存在一些差异。
考虑这个问题的最简单方法是从空白开始MockHttpServletRequest. 无论你添加什么，请求都会变成什么样子。可能会让你措手不及的事情是默认情况下没有上下文路径; 不jsessionid饼干; 没有转发、错误或异步调度;因此，没有实际的 JSP 渲染。 相反 “转发”和“重定向”URL 保存在MockHttpServletResponse并且可以以期望来断言。
这意味着，如果您使用 JSP，您可以验证请求被转发的 JSP 页面转发，但不会呈现 HTML。换句话说，不会调用 JSP。 注意 但是，所有其他不依赖转发的渲染技术，例如Thymeleaf 和 Freemarker，都会按预期将 HTML 渲染到响应正文。同样用于通过@ResponseBody方法。
或者，您可以考虑从Spring Boot 与@SpringBootTest. 请参阅 Spring Boot 参考指南。
每种方法各有利弊。Spring MVC Test 中提供的选项是从经典单元测试到完全集成测试的不同站点。要成为当然，Spring MVC Test 中没有一个选项属于经典单元类别测试，但它们更接近它。例如，您可以隔离 Web 层通过将模拟服务注入控制器，在这种情况下，您正在测试 Web层仅通过DispatcherServlet但是在实际的 Spring 配置中，因为您可能会与其上方的层隔离地测试数据访问层。此外，您还可以使用独立设置，一次专注于一个控制器并手动提供使其工作所需的配置。
使用 Spring MVC Test 时的另一个重要区别是，从概念上讲，这样的tests 是服务器端测试，因此您可以检查使用了什么处理程序，如果异常是用HandlerExceptionResolver，模型的内容是什么，绑定错误，以及其他细节。这意味着更容易编写期望，由于服务器不是一个不透明的盒子，就像通过实际的 HTTP 测试它时那样 客户。 这通常是经典单元测试的一个优势：它更容易编写、推理和调试，但不能取代完全集成测试的需求。在同时，重要的是不要忽视这样一个事实，即响应是最重要的检查的重要事情。简而言之，有多种风格和策略的空间即使在同一个项目中也能进行测试。