MockMvc 与端到端测试
MockMvc 构建在模块的 Servlet API 模拟实现之上,不依赖于正在运行的容器。因此,有
与使用实际
客户端和正在运行的实时服务器。spring-test
考虑这个问题的最简单方法是从空白 .
无论你添加什么,请求都会变成什么。可能会让您感到意外的事情
是默认情况下没有上下文路径;没有 cookie;无转发,
error 或 async dispatches;因此,没有实际的 JSP 呈现。相反
“forwarded” 和 “redirected” URL 保存在 和 可以
带着期望断言。MockHttpServletRequest
jsessionid
MockHttpServletResponse
这意味着,如果您使用 JSP,则可以验证请求所指向的 JSP 页面
转发,但未呈现任何 HTML。换句话说,不调用 JSP。注意
但是,所有其他不依赖于转发的渲染技术(例如
Thymeleaf 和 Freemarker 按预期将 HTML 呈现到响应正文。同样的情况
用于通过方法呈现 JSON、XML 和其他格式。@ResponseBody
或者,您可以考虑从
带有 .请参阅 Spring Boot 参考指南。@SpringBootTest
每种方法都有优点和缺点。Spring MVC Test 中提供的选项包括
从经典的单元测试到完整的集成测试,规模上的站点各不相同。成为
当然,Spring MVC Test 中的任何选项都不属于经典单元的范畴
测试,但他们离它更近一些。例如,您可以隔离 Web 图层
通过将模拟服务注入控制器,在这种情况下,您正在测试 Web
层仅通过 但具有实际的 Spring 配置,因为
可能会独立于其上方的层测试数据访问层。此外,您还可以使用
独立设置,一次专注于一个控制器,并手动提供
使其正常工作所需的配置。DispatcherServlet
使用 Spring MVC Test 时的另一个重要区别是,从概念上讲,这样的
测试是服务器端测试,因此如果出现异常,您可以检查使用了哪个处理程序
用一个处理,模型的内容是什么,绑定什么
那里有错误,还有其他细节。这意味着编写 expectations 更容易,
因为服务器不是一个不透明的盒子,就像通过实际的 HTTP 测试它时一样
客户。这通常是经典单元测试的一个优点:它更容易编写,
reason 和 debug 的 SET 的 SET 的 TEST 的 SET 的 TEST 的 SET 的 U 的 U在
同时,重要的是不要忽视一个事实,即反应是最
需要检查的重要事项。简而言之,有多种风格和策略的空间
的测试。HandlerExceptionResolver