这可能是解决你Spring MVC接口漏洞百出的关键

在 Java 开发中接触的开发者大多数不太注重对接口的测试,结果在联调对接中出现各种问题。也有的使用 Postman 等工具进行测试,虽然在使用上没有什么问题,如果接口增加了权限测试起来就比较恶心了。
首页 新闻资讯 行业资讯 这可能是解决你Spring MVC接口漏洞百出的关键

[[346147]]

1. 前言

在 Java 开发中接触的开发者大多数不太注重对接口的测试,结果在联调对接中出现各种问题。也有的使用 Postman  等工具进行测试,虽然在使用上没有什么问题,如果接口增加了权限测试起来就比较恶心了。所以建议在单元测试中测试接口,保证在交付前先自测接口的健壮性。今天就来分享一下胖哥在开发中是如何对  Spring MVC 接口进行测试的。

在开始前请务必确认添加了Spring Boot Test相关的组件,在最新的版本中应该包含以下依赖:

复制

<dependency>     <groupId>org.springframework.boot</groupId>     <artifactId>spring-boot-starter-test</artifactId>     <scope>test</scope>     <exclusions>         <exclusion>             <groupId>org.junit.vintage</groupId>             <artifactId>junit-vintage-engine</artifactId>         </exclusion>     </exclusions> </dependency>
  • 1.

  • 2.

  • 3.

  • 4.

  • 5.

  • 6.

  • 7.

  • 8.

  • 9.

  • 10.

  • 11.

本文是在Spring Boot 2.3.4.RELEASE下进行的。

2. 单独测试控制层

如果我们只需要对控制层接口(Controller)进行测试,且该接口不依赖@Service、@Component等注解声明的 Spring Bean  时,可以借助@WebMvcTest来启用只针对 Web 控制层的测试,例如

复制

@WebMvcTest class CustomSpringInjectApplicationTests {     @Autowired     MockMvc mockMvc;      @SneakyThrows     @Test     void contextLoads() {         mockMvc.perform(MockMvcRequestBuilders.get("/foo/map"))                 .andExpect(ResultMatcher.matchAll(status().isOk(),                         content().contentType(MediaType.APPLICATION_JSON),                         jsonPath("$.test", Is.is("hello"))))                 .andDo(MockMvcResultHandlers.print());     }  }
  • 1.

  • 2.

  • 3.

  • 4.

  • 5.

  • 6.

  • 7.

  • 8.

  • 9.

  • 10.

  • 11.

  • 12.

  • 13.

  • 14.

  • 15.

  • 16.

这种方式要快的多,它只加载了应用程序的一小部分。但是如果你涉及到服务层这种方式是不凑效的,我们就需要整体测试了方了。

3. 整体测试

大多数 Spring Boot 下的接口测试是整体而又全面的测试,涉及到控制层、服务层、持久层等方方面面,所以需要加载比较完整的 Spring Boot  上下文。这时我们可以这样做,声明一个抽象的测试基类:

复制

package cn.felord.custom;  import org.springframework.beans.factory.annotation.Autowired; import org.springframework.boot.test.autoconfigure.web.servlet.AutoConfigureMockMvc; import org.springframework.boot.test.context.SpringBootTest; import org.springframework.test.web.servlet.MockMvc;   /**  * 测试基类,  * @author felord.cn  */ @SpringBootTest @AutoConfigureMockMvc abstract class CustomSpringInjectApplicationTests {     /**      * The Mock mvc.      */     @Autowired     MockMvc mockMvc;     // 其它公共依赖和处理方法 }
  • 1.

  • 2.

  • 3.

  • 4.

  • 5.

  • 6.

  • 7.

  • 8.

  • 9.

  • 10.

  • 11.

  • 12.

  • 13.

  • 14.

  • 15.

  • 16.

  • 17.

  • 18.

  • 19.

  • 20.

  • 21.

  • 22.

只有当@AutoConfigureMockMvc存在时MockMvc才会被注入 Spring IoC。

然后针对具体的控制层进行如下测试代码的编写:

复制

package cn.felord.custom;  import lombok.SneakyThrows; import org.hamcrest.core.Is; import org.junit.jupiter.api.Test; import org.springframework.http.MediaType; import org.springframework.test.web.servlet.ResultMatcher; import org.springframework.test.web.servlet.request.MockMvcRequestBuilders; import org.springframework.test.web.servlet.result.MockMvcResultHandlers;  import static org.springframework.test.web.servlet.result.MockMvcResultMatchers.*;  /**  * 测试FooController.  *  * @author felord.cn  */ public class FooTests extends CustomSpringInjectApplicationTests {     /**      * /foo/map接口测试.      */     @SneakyThrows     @Test     void contextLoads() {         mockMvc.perform(MockMvcRequestBuilders.get("/foo/map"))                 .andExpect(ResultMatcher.matchAll(status().isOk(),                         content().contentType(MediaType.APPLICATION_JSON),                         jsonPath("$.test", Is.is("bar"))))                 .andDo(MockMvcResultHandlers.print());     } }
  • 1.

  • 2.

  • 3.

  • 4.

  • 5.

  • 6.

  • 7.

  • 8.

  • 9.

  • 10.

  • 11.

  • 12.

  • 13.

  • 14.

  • 15.

  • 16.

  • 17.

  • 18.

  • 19.

  • 20.

  • 21.

  • 22.

  • 23.

  • 24.

  • 25.

  • 26.

  • 27.

  • 28.

  • 29.

  • 30.

  • 31.

4. MockMvc 测试

集成测试时,希望能够通过输入 URL 对 Controller 进行测试,如果通过启动服务器,建立 http client  进行测试,这样会使得测试变得很麻烦,比如,启动速度慢,测试验证不方便,依赖网络环境等,为了可以对 Controller  进行测试,所以引入了MockMvc。

MockMvc实现了对 Http 请求的模拟,能够直接使用网络的形式,转换到 Controller  的调用,这样可以使得测试速度快、不依赖网络环境,而且提供了一套验证的工具,这样可以使得请求的验证统一而且很方便。接下来我们来一步步构造一个测试的模拟请求,假设我们存在一个下面这样的接口:

复制

@RestController @RequestMapping("/foo") public class FooController {     @Autowired     private MyBean myBean;      @GetMapping("/user")     public Map<String, String> bar(@RequestHeader("Api-Version") String apiVersion, User user) {         Map<String, String> map = new HashMap<>();         map.put("test", myBean.bar());         map.put("version", apiVersion);         map.put("username", user.getName());         //todo your business         return map;     } }
  • 1.

  • 2.

  • 3.

  • 4.

  • 5.

  • 6.

  • 7.

  • 8.

  • 9.

  • 10.

  • 11.

  • 12.

  • 13.

  • 14.

  • 15.

  • 16.

参数设定为name=felord.cn&age=18,那么对应的 HTTP 报文是这样的:

复制

GET /foo/user?name=felord.cn&age=18 HTTP/1.1 Host: localhost:8888 Api-Version: v1
  • 1.

  • 2.

  • 3.

可以预见的返回值为:

复制

{     "test": "bar",     "version": "v1",     "username": "felord.cn" }
  • 1.

  • 2.

  • 3.

  • 4.

  • 5.

事实上对接口的测试可以分为以下几步。

构建请求

构建请求由MockMvcRequestBuilders负责,他提供了请求方法(Method),请求头(Header),请求体(Body),参数(Parameters),会话(Session)等所有请求的属性构建。/foo/user接口的请求可以转换为:

复制

MockMvcRequestBuilders.get("/foo/user")                 .param("name", "felord.cn")                 .param("age", "18")                 .header("Api-Version", "v1")
  • 1.

  • 2.

  • 3.

  • 4.

执行 Mock 请求

然后由MockMvc执行 Mock 请求:

复制

mockMvc.perform(MockMvcRequestBuilders.get("/foo/user")                 .param("name", "felord.cn")                 .param("age", "18")                 .header("Api-Version", "v1"))
  • 1.

  • 2.

  • 3.

  • 4.

对结果进行处理

请求结果被封装到ResultActions对象中,它封装了多种让我们对 Mock 请求结果进行处理的方法。

对结果进行预期期望

ResultActions#andExpect(ResultMatcher  matcher)方法负责对响应的结果的进行预期期望,看看是否符合测试的期望值。参数ResultMatcher负责从响应对象中提取我们需要期望的部位进行预期比对。

假如我们期望接口/foo/user返回的是JSON,并且 HTTP 状态为200,同时响应体包含了version=v1的值,我们应该这么声明:

复制

ResultMatcher.matchAll(MockMvcResultMatchers.status().isOk(),                MockMvcResultMatchers.content().contentType(MediaType.APPLICATION_JSON),                MockMvcResultMatchers.jsonPath("$.version", Is.is("v1")));
  • 1.

  • 2.

  • 3.

JsonPath是一个强大的 JSON 解析类库,请通过其项目仓库https://github.com/json-path/JsonPath了解。

对响应进行处理

ResultActions#andDo(ResultHandler handler)方法负责对整个请求/响应进行打印或者 log  输出、流输出,由MockMvcResultHandlers工具类提供这些方法。我们可以通过以上三种途径来查看请求响应的细节。

例如/foo/user接口:

复制

MockHttpServletRequest:       HTTP Method = GET       Request URI = /foo/user        Parameters = {name=[felord.cn], age=[18]}           Headers = [Api-Version:"v1"]              Body = null     Session Attrs = {}  Handler:              Type = cn.felord.xbean.config.FooController            Method = cn.felord.xbean.config.FooController#urlEncode(String, Params)  Async:     Async started = false      Async result = null  Resolved Exception:              Type = null  ModelAndView:         View name = null              View = null             Model = null  FlashMap:        Attributes = null  MockHttpServletResponse:            Status = 200     Error message = null           Headers = [Content-Type:"application/json"]      Content type = application/json              Body = {"test":"bar","version":"v1","username":"felord.cn"}     Forwarded URL = null    Redirected URL = null           Cookies = []
  • 1.

  • 2.

  • 3.

  • 4.

  • 5.

  • 6.

  • 7.

  • 8.

  • 9.

  • 10.

  • 11.

  • 12.

  • 13.

  • 14.

  • 15.

  • 16.

  • 17.

  • 18.

  • 19.

  • 20.

  • 21.

  • 22.

  • 23.

  • 24.

  • 25.

  • 26.

  • 27.

  • 28.

  • 29.

  • 30.

  • 31.

  • 32.

  • 33.

  • 34.

  • 35.

  • 36.

获取返回结果

如果你希望进一步处理响应的结果,也可以通过ResultActions#andReturn()拿到MvcResult类型的结果进行进一步的处理。

完整的测试过程

通常andExpect是我们必然会选择的,而andDo和andReturn在某些场景下会有用,它们两个是可选的。我们把上面的连在一起。

复制

@Autowired MockMvc mockMvc;  @SneakyThrows @Test void contextLoads() {       mockMvc.perform(MockMvcRequestBuilders.get("/foo/user")             .param("name", "felord.cn")             .param("age", "18")             .header("Api-Version", "v1"))             .andExpect(ResultMatcher.matchAll(status().isOk(),                     content().contentType(MediaType.APPLICATION_JSON),                     jsonPath("$.version", Is.is("v1"))))             .andDo(MockMvcResultHandlers.print());  }
  • 1.

  • 2.

  • 3.

  • 4.

  • 5.

  • 6.

  • 7.

  • 8.

  • 9.

  • 10.

  • 11.

  • 12.

  • 13.

  • 14.

  • 15.

  • 16.

  • 17.

这种流式的接口单元测试从语义上看也是比较好理解的,你可以使用各种断言、正例、反例测试你的接口,最终让你的接口更加健壮。

5. 总结

一旦你熟练了这种方式,你编写的接口将更加具有权威性而不会再漏洞百出,甚至有时候你也可以使用 Mock 来设计接口,使之更加贴合业务。所以 CRUD  不是完全没有技术含量,高质量高效率的 CRUD 往往需要这种工程化的单元测试来支撑。

本文转载自微信公众号「码农小胖哥」,可以通过以下二维码关注。转载本文请联系码农小胖哥公众号。

 

16    2020-10-14 09:46:33    Spring MVC 接口 漏洞