此版本仍在开发中,尚不被认为是稳定的。对于最新的稳定版本,请使用 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 中提供的选项包括
从经典单元测试到完全集成测试的不同站点。成为
当然,春季 MVC 测试中的任何选项都不属于经典单元类别
测试,但他们离它更近了一点。例如,您可以隔离 Web 图层
通过将模拟服务注入控制器,在这种情况下,您正在测试 Web
层仅通过DispatcherServlet
但使用实际的 Spring 配置,就像你一样
可能会将数据访问层与其上方的层隔离开来测试。此外,您还可以使用
独立设置,一次专注于一个控制器并手动提供
使其正常工作所需的配置。
使用 Spring MVC Test 时的另一个重要区别是,从概念上讲,例如
测试是服务器端测试,因此如果出现异常,您可以检查使用了什么处理程序
用HandlerExceptionResolver
,模型的内容是什么,绑定是什么
有错误,还有其他细节。这意味着写期望更容易,
因为服务器不是一个不透明的盒子,就像通过实际的 HTTP 测试它时那样
客户。这通常是经典单元测试的一个优点:它更容易编写,
原因和调试,但不能取代完全集成测试的需要。在
同时,重要的是不要忽视这样一个事实,即响应最多
要检查的重要事项。总之,多种风格和策略都有空间
甚至在同一项目内进行测试。