企业官网建设流程全解析

1. MockMvc在测什么：不启动Tomcat也能走完整个MVC链路

1.1 MockMvc的工作边界到底在哪

先回答很多人第一次接触MockMvc时的疑问：我在浏览器和Postman里已经能调接口了，为什么还要在项目里写一套MockMvc测试？原因在于，Postman验证的是"接口当前是否正常"，而MockMvc验证的是"接口以后会不会被改坏"。它不需要启动真实的Tomcat容器，也不占用端口，而是通过MockHttpServletRequest和MockHttpServletResponse，把一次HTTP请求直接送到Spring MVC的DispatcherServlet里，让Controller、过滤器、拦截器、参数解析、HttpMessageConverter、@Valid校验、异常处理全部走一遍。

换句话说，MockMvc测的是Spring MVC内部处理请求的整条行为链路，而不是真实的网络链路。网络超时、Nginx转发、网关路由这些问题它管不了，但它能精准地告诉你：这个GET接口传这样的参数，返回的JSON字段是否符合预期；这个POST接口用这样的请求体，状态码和数据结构对不对。对做接口回归测试来说，这恰好是价值密度最高的部分。

基于这个边界，MockMvc适合下面几类人：

• 正在给Spring Boot项目补测试，想把Controller层的参数绑定、校验、响应结果沉淀成自动化用例；
• 项目里接口越来越多，提PR前想快速验证老接口有没有被改坏；
• 面试前想搞清楚MockMvc与真实HTTP请求、与Postman验证之间的本质区别。

本文所有示例都围绕"GET和POST接口、单个与多个请求参数"展开，对应的Spring Boot版本我按3.x来写，2.x也基本通用，遇到版本差异我会单独标注。

1.2 最小依赖和测试类骨架：先把地基打好

要让MockMvc跑起来，最省事的做法是引入spring-boot-starter-test，它已经聚合了JUnit Jupiter、Spring Test、Jackson、JsonPath、Hamcrest、Mockito等MockMvc测试需要的组件，不需要再手动补一堆依赖。

<dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-test</artifactId> <scope>test</scope> </dependency>

测试类的基础写法是这样：

import org.junit.jupiter.api.Test; 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; @SpringBootTest @AutoConfigureMockMvc class UserControllerTest { @Autowired private MockMvc mockMvc; }

@SpringBootTest会加载完整的Spring应用上下文，@AutoConfigureMockMvc负责注入MockMvc实例。这里我多说一句：@SpringBootTest默认的webEnvironment是MOCK，也就是不启动真实服务器，只模拟一个Servlet环境。千万不要手动改成RANDOM_PORT或DEFINED_PORT去测MockMvc，那等于绕远路，没必要。

如果你用的是JUnit4，还需要在类上加@RunWith(SpringRunner.class)；JUnit5则不需要，@SpringBootTest已经集成了SpringExtension的能力。

另外有个很容易踩的坑：测试类的位置要放在主启动类所在包或者它的子包下。如果测试类放到一个独立的包路径里，Spring Boot扫描不到@SpringBootConfiguration，测试启动会直接报错。项目结构不规范的团队经常遇到这个，我建议新建项目时就把controller、service、test的包路径提前规划好。

再提一个取舍：@WebMvcTest只加载Controller层相关的切片，不加载Service和数据源，配合@MockBean可以跑得更快。但它需要额外mock掉所有依赖，适合纯Controller单元测试。如果你只是想验证接口的完整行为，@SpringBootTest + @AutoConfigureMockMvc这种全上下文方式更省心。两种方案没有谁绝对更好，看测试目的。

2. GET接口测试：单个参数、多个参数与路径参数的三种写法

2.1 一个用于演示的UserController

为了让后面的测试代码可以直接抄，我准备了一个精简版UserController，涵盖GET和POST的常见参数形态。真实项目里的Controller会调Service，这里我先用接口注入，测试时用@MockBean打桩，避免把文章重心带到数据库和事务上。

@RestController @RequestMapping("/api/users") public class UserController { private final UserService userService; public UserController(UserService userService) { this.userService = userService; } @GetMapping("/{id}") public User getUserById(@PathVariable Long id) { return userService.getById(id); } @GetMapping("/byName") public User getByName(@RequestParam("name") String name) { return userService.getByName(name); } @GetMapping public PageResult<User> queryUsers(UserQuery query) { return userService.queryUsers(query); } @GetMapping("/byIds") public List<User> getByIds(@RequestParam("ids") List<Long> ids) { return userService.getByIds(ids); } @PostMapping @ResponseStatus(HttpStatus.CREATED) public User createUser(@RequestBody @Valid User user) { return userService.create(user); } @PostMapping("/import") public List<User> importUsers(@RequestBody List<User> users) { return userService.batchSave(users); } @PostMapping("/form") public User createByForm(UserForm form) { return userService.create(form.toUser()); } }

UserService这里不做完整定义，你只需要知道它的方法签名和Controller一一对应即可。测试时用@MockBean替换成桩方法，就可以完全控制返回结果，专心测Controller层的参数绑定和响应结构。User类我按常规写：Long id、String name、Integer age、String email，必须有getter/setter和无参构造器，否则Jackson序列化和Spring参数绑定都会出问题。

2.2 单参数：@RequestParam与param()的对应关系

先看单个查询参数怎么测。Controller里用@RequestParam("name")接收name，MockMvc侧就用param("name", "张三")：

import static org.springframework.test.web.servlet.request.MockMvcRequestBuilders.get; import static org.springframework.test.web.servlet.result.MockMvcResultMatchers.status; import static org.springframework.test.web.servlet.result.MockMvcResultMatchers.jsonPath; import static org.hamcrest.Matchers.is; @Test void getByName_shouldReturnUser() throws Exception { when(userService.getByName("张三")).thenReturn(new User(1L, "张三", 20, "zhang@example.com")); mockMvc.perform(get("/api/users/byName") .param("name", "张三")) .andExpect(status().isOk()) .andExpect(jsonPath("$.name").value("张三")); }

param()这个方法会把参数拼到请求的query string上，最终等价于访问/api/users/byName?name=张三。它的底层行为是往MockHttpServletRequest的参数Map里放值，DispatcherServlet再按照参数名去匹配Controller方法里的@RequestParam。

这里有一个新手特别容易忽略的细节：@RequestParam("name")这种写法，param()里的key必须和注解里的value一致。如果Controller里写的是@RequestParam("userName")，测试里传param("name", ...)，参数就会变成null，接口能走到方法里，但拿到的值不对。而如果你用@RequestParam String name这种不指名的方式，Spring需要依赖编译期保留的parameter name信息，有些Maven配置没开-parameters参数时也会绑定失败。最稳妥的做法是：Controller侧和测试侧都显式把参数名写清楚，不要依赖隐式规则。

再来看路径参数。Controller里是@GetMapping("/{id}")，MockMvc的写法是用花括号占位符，而不是自己拼字符串：

@Test void getUserById_shouldReturnUser() throws Exception { when(userService.getById(1L)).thenReturn(new User(1L, "张三", 20, "zhang@example.com")); mockMvc.perform(get("/api/users/{id}", 1L)) .andExpect(status().isOk()) .andExpect(jsonPath("$.id").value(1)) .andExpect(jsonPath("$.name").value("张三")); }

get("/api/users/{id}", 1L)里的1L会被UriTemplate自动填充到路径中。这样做的好处是避免手写字符串拼接出错，还可以让MockMvc对路径变量做类型匹配检查。路径参数看起来简单，但它和@RequestParam在请求中的位置完全不同，测试代码也对应两种风格，不要混用。

2.3 多参数：对象绑定、多个同名参数与List接收

接口参数一多，很多人就不知道怎么测了。最常见的场景是查询列表，条件有page、size、name。在Controller里直接声明一个UserQuery对象接收，Spring会把query string里的参数按名称绑定到对象属性上：

public class UserQuery { private Integer page; private Integer size; private String name; // getter/setter }

MockMvc侧的做法就是连续多个param()：

@Test void queryUsers_withMultipleParams_shouldReturnPage() throws Exception { PageResult<User> pageResult = new PageResult<>(); pageResult.setContent(Arrays.asList( new User(1L, "张三", 20, "zhang@example.com"), new User(2L, "李四", 25, "li@example.com") )); pageResult.setTotal(2); when(userService.queryUsers(any(UserQuery.class))).thenReturn(pageResult); mockMvc.perform(get("/api/users") .param("page", "0") .param("size", "10") .param("name", "张")) .andExpect(status().isOk()) .andExpect(jsonPath("$.content.length()").value(2)) .andExpect(jsonPath("$.content[0].name").value("张三")); }

这个例子里参数绑定的原理是：多个param()最终拼成?page=0&size=10&name=张，Spring的WebDataBinder按属性名反射绑定到UserQuery。所以UserQuery必须有setter方法，字段名要和param()的key完全对应。另外，如果某个整型字段传了非数字字符串，类型转换失败会抛TypeMismatchException，接口返回400，这在回归测试里是个很有价值的断言点。

再一个场景：多个同名参数绑到List。比如根据一批ID查询用户：

@GetMapping("/byIds") public List<User> getByIds(@RequestParam("ids") List<Long> ids) { ... }

MockMvc的正确写法是：

mockMvc.perform(get("/api/users/byIds") .param("ids", "1") .param("ids", "2") .param("ids", "3")) .andExpect(status().isOk()) .andExpect(jsonPath("$.length()").value(3));

param这个方法签名是param(String name, String... values)，它支持同一个name传入多个value，最终在Servlet层面形成多个同名query参数，Controller侧再用List 接收。这里我要特别提醒：有人习惯写成param("ids", "1,2,3")，想让Spring按逗号分隔自动转成List。这个行为依赖Spring内置的StringToCollectionConverter，确实有可能拆分成功，但它把"多个值"和"一个逗号字符串"混为一谈，当你在做多值参数测试时，最符合HTTP协议语义的写法永远是多个同名参数，而不是逗号拼接。这个坑在后面的排查实录里我还会详细讲。

3. POST接口测试：JSON请求体、集合请求体与表单提交

3.1 单个对象请求体：ObjectMapper与content配合

POST接口的核心区别在于：请求数据通常在请求体里，而不是query string里。最常见的写法是@RequestBody接收JSON对象：

@PostMapping @ResponseStatus(HttpStatus.CREATED) public User createUser(@RequestBody @Valid User user) { return userService.create(user); }

测试代码：

@Autowired private ObjectMapper objectMapper; @Test void createUser_withJsonBody_shouldCreateUser() throws Exception { User newUser = new User(null, "王五", 28, "wang@example.com"); when(userService.create(any(User.class))).thenReturn(newUser); String json = objectMapper.writeValueAsString(newUser); mockMvc.perform(post("/api/users") .contentType(MediaType.APPLICATION_JSON) .content(json)) .andExpect(status().isCreated()); }

这里有一个很容易踩的坑：POST接口用@RequestBody接收参数，但测试里只调param()不写content()。因为@RequestBody的数据来源于HTTP body输入流，而param()只会往参数Map里塞值，body永远是空的。即使接口返回200，Controller里收到的User对象也全是null。反过来，如果Controller方法没有@RequestBody，只是普通对象参数，你传JSON body它也不会自动绑定。

另一个关键点是contentType。@RequestBody的数据解析依赖HttpMessageConverter，而Converter是根据Content-Type选择消息转换器的。如果你不设置contentType，MockMvc默认没有这个请求头，DispatcherServlet找不到合适的Converter，就会抛HttpMediaTypeNotSupportedException，最终返回415。我第一次写JSON接口测试时就在这里卡了半小时，印象极其深刻。

我建议所有POST的JSON请求体都用ObjectMapper序列化，而不是手写JSON字符串。原因有两个：第一，手写字符串很容易漏引号或转义错误，犯错率极高；第二，项目中配置了LocalDateTime格式、字段命名规则等Jackson特性后，用ObjectMapper生成的JSON和真实请求完全一致，不会出现"测试通过但联调挂掉"的偏差。

如果你在Spring Boot 3.4+的项目里看到@MockBean标了deprecated，不用慌，把@MockBean换成@MockitoBean就行，语义完全一样，旧写法依然能跑。代码里的any(User.class)来自Mockito的静态导入，断言时如果还希望覆盖Bean Validation的校验分支，可以构造一个缺字段的对象，比如{"name":"","age":200}，预期返回400，这也值得单独写一条用例。

3.2 多个对象请求体：@RequestBody List 的序列化

当接口需要一次接收一批数据时，Controller通常写成：

@PostMapping("/import") public List<User> importUsers(@RequestBody List<User> users) { ... }

测试时，关键一步是把List 序列化成JSON数组：

@Test void importUsers_withJsonArray_shouldReturnImportedList() throws Exception { List<User> users = Arrays.asList( new User(null, "赵一", 22, "zhao@example.com"), new User(null, "钱二", 30, "qian@example.com") ); when(userService.batchSave(anyList())).thenReturn(users); String json = objectMapper.writeValueAsString(users); mockMvc.perform(post("/api/users/import") .contentType(MediaType.APPLICATION_JSON) .content(json)) .andExpect(status().isOk()) .andExpect(jsonPath("$.length()").value(2)) .andExpect(jsonPath("$[0].name").value("赵一")); }

$在JsonPath里代表整个JSON根节点，对于JSON数组，$.length()就是数组长度，$[0].name表示第一个元素的name字段。新增数据这种接口通常会带@Valid逐个校验列表元素，如果你把某个元素构造为非法数据，响应就会带上校验错误信息，同样可以用jsonPath断言出来。

这里我想多说一下集合反序列化的底层逻辑。@RequestBody List 的泛型信息是公开的，Jackson可以根据方法签名推断出目标类型是List ，然后调用相应的集合解析逻辑。但如果你把参数类型写成@RequestBody Object body，Jackson就只能按默认规则反序列化成一个List edhashmap> ，后续再手动转换类型就会很痛苦。所以接口参数该明确类型就明确类型，这对MockMvc测试的断言也有直接好处。

3.3 表单请求体：别让Content-Type骗了你

不是所有POST都走JSON。传统表单提交的场景，Controller用普通表单对象接收：

public class UserForm { private String username; private Integer age; private String email; // getter/setter public User toUser() { return new User(null, this.username, this.age, this.email); } } @PostMapping("/form") public User createByForm(UserForm form) { return userService.create(form.toUser()); }

表单测试的正确写法是显式设置Content-Type为application/x-www-form-urlencoded，然后用param()传表单字段：

@Test void createUser_withFormData_shouldCreateUser() throws Exception { User created = new User(3L, "孙七", 35, "sun@example.com"); when(userService.create(any(User.class))).thenReturn(created); mockMvc.perform(post("/api/users/form") .contentType(MediaType.APPLICATION_FORM_URLENCODED) .param("username", "孙七") .param("age", "35")) .andExpect(status().isOk()) .andExpect(jsonPath("$.name").value("孙七")); }

注意，表单字段的key要和UserForm的属性名一致。这里的username字段映射到JavaBean的username属性，如果你测试里写param("name", ...)，绑定就会失败。另外，表单场景下Content-Type决定了Spring如何解析请求体，如果你把Content-Type设为application/json，但Controller侧又是普通表单对象参数，就很容易出现参数绑不上或者直接报错的情况。POST接口的数据位置和Content-Type组合决定了参数能否正确到达方法，写测试前先把Controller方法签名看明白，能省下大量排查时间。

如果你遇到了"POST表单多个同名参数"的场景，比如多选爱好，正确的写法是：

mockMvc.perform(post("/api/users/form") .contentType(MediaType.APPLICATION_FORM_URLENCODED) .param("hobbies", "阅读") .param("hobbies", "跑步"))

这种写法对应Servlet层的getParameterValues()，Spring会把它装配成List 。很多初学MockMvc的人习惯把多个值拼成一个字符串传过去，那样拿到的是一个包含单一元素"阅读,跑步"的List，后面业务逻辑算错都找不到原因。

4. 排查实录：POST请求参数为什么进不了Controller

4.1 现象：测试返回415而不是预期结果

有一次我带新人做代码练习，他写了一个POST接口用于保存用户，Controller签名是标准的@RequestBody @Valid User。他的MockMvc测试这样写：

mockMvc.perform(post("/api/users/save") .param("name", "张三") .param("age", "20")) .andExpect(status().isOk());

结果测试直接爆红。控制台抛出的异常是HttpMediaTypeNotSupportedException，MockMvcResultMatchers给出的是415状态码。他第一反应是"接口是不是写错了"，然后打开Postman手动请求了一遍，又确认接口本身没问题。这就出现了典型的"Postman能通，MockMvc不通"的悖论。

这个现象在团队里出现过多次，根本原因基本都和请求参数的位置有关系。Postman里大家习惯手动切换到Body tab，输入JSON，自动带上Content-Type；但写MockMvc测试时，人的大脑还停留在"我要传参数"这件事上，不自觉就用了param()。param()确实把参数传进去了，但传的是query parameters，而不是request body。

4.2 从print()日志中找证据：Headers为空，Body为null

遇到MockMvc断言失败，不要急着改代码，第一步就是把请求和响应的完整信息打出来。在perform后面加.andDo(print())，测试运行时控制台会输出MockHttpServletRequest和MockHttpServletResponse的完整结构。

那次新人加了print()之后，我们看到的关键信息是这样的：

MockHttpServletRequest: HTTP Method = POST Request URI = /api/users/save Parameters = {name=[张三], age=[20]} Headers = [] Body = null

两行信息直接击中问题本质：Headers是空的，说明没有Content-Type；Body是null，说明请求体为空。@RequestBody的解析依赖HttpMessageConverter，而Converter需要从Content-Type判断用什么解析器；Body是null则意味着即使有Converter，也没有数据可读。

一句话总结这个场景：param()只负责填充请求参数Map，而@RequestBody需要请求体输入流。这两条数据线在Servlet层是完全分开的，MockMvc虽然不经过真实网络端口，但它的MockHttpServletRequest同样遵守这个行为模型。

4.3 修复：JSON场景必须content+contentType组合

修复方法就是把param()换成content()，并显式声明Content-Type：

User newUser = new User(null, "张三", 20, "zhang@example.com"); String json = objectMapper.writeValueAsString(newUser); mockMvc.perform(post("/api/users/save") .contentType(MediaType.APPLICATION_JSON) .content(json)) .andExpect(status().isOk()) .andExpect(jsonPath("$.name").value("张三"));

改完之后再跑，测试通过。这个排查链路可以沉淀成一个判断规则：当你准备用MockMvc测POST接口时，先看Controller方法签名里有没有@RequestBody。有，就用content()+contentType(APPLICATION_JSON)；没有，才考虑param()表单绑定。这个规则几乎能覆盖90%的MockMvc参数测试问题。

4.4 延伸：多个同名参数时，代码里到底传成了几个值

和上面这个坑并列的，是多个请求参数场景里的"逗号拼接"问题。有位同事在做用户资料接口测试时，发现接口返回正常，但进入Service后hobbies参数始终只有一段文字，前面搭的页面显示也不对。

他测试里写的是：

mockMvc.perform(post("/api/users/hobbies") .contentType(MediaType.APPLICATION_FORM_URLENCODED) .param("hobbies", "阅读,跑步"))

Controller对应参数是：

@RequestParam("hobbies") List<String> hobbies

趁print()的机会，我们注意到MockHttpServletRequest的Parameters输出是hobbies=[阅读,跑步]，看起来像是一个字符串值。而正确模拟"多个同参数值"的写法应该是：

.param("hobbies", "阅读") .param("hobbies", "跑步")

print()之后Parameters会显示hobbies=[阅读,跑步]，注意这里的方括号是Collections.toString的效果，代表这个key对应两个values，Controller拿到的List是["阅读", "跑步"]。

这两种写法的区别很细微，但结果差异很大。Spring的StringToCollectionConverter确实支持把逗号分隔的字符串拆成集合，但它是"拆完再包装成List"，和Servlet协议中真正的多值参数存在语义差。为了测试代码准确反映HTTP请求的真实形态，遇到List类型参数，一律用多个param()。这一条也建议写进团队的MockMvc测试规范。

5. 让MockMvc测试稳定落地：回滚、安全、编码与工具分工

5.1 测试数据回滚：@Transactional的正确姿势

如果你的测试不是用@MockBean打桩，而是跑了完整Service链路，POST接口每执行一次就会往数据库写一条数据。测试跑完后数据库越来越脏，是很多团队的痛点。Spring Test提供了一个很轻量的方案：测试类上加@Transactional。

@SpringBootTest @AutoConfigureMockMvc @Transactional class UserControllerTest { ... }

加了@Transactional之后，Spring会把每个测试方法包在一个事务里，测试结束自动回滚，数据库保持测试前的状态。这个方案我用了很久，基本不用再写繁琐的"清理数据"逻辑。

但它也有一个隐藏坑：如果Service方法用了@Transactional(propagation = Propagation.REQUIRES_NEW)，Service内部会新开一个独立事务，这个事务不再跟随测试事务回滚。同理，@Async异步方法执行时可能已经跨了线程，回滚也覆盖不到。遇到这种情况，要么在测试里手动清理关联数据，要么用@MockBean把这类方法替换成桩。写完整链路测试前，先扫一眼Service层的Transaction注解配置，能避免很多"测试跑完数据库多了垃圾数据"的问题。

5.2 项目里加了Spring Security，MockMvc怎么配

Spring Boot项目一旦引入spring-boot-starter-security，MockMvc测试默认会加载安全过滤器链。这时你的GET接口可能直接返回401或302跳到登录页，POST接口还可能因为CSRF防护被403拦截。很多团队第一次把MockMvc测试加到已有项目里，第一个红色用例就是被安全策略拦下来的。

解决思路要看你的测试目标。如果目的是验证业务接口逻辑，不想被安全配置干扰，有两种选择：一是用Spring Security测试支持库，给请求加上用户身份和CSRF令牌；二是通过@AutoConfigureMockMvc(addFilters = false)关闭过滤器链。

我推荐优先用前一种，因为过滤器行为本身就是接口行为的一部分。先在pom里引入依赖：

<dependency> <groupId>org.springframework.security</groupId> <artifactId>spring-security-test</artifactId> <scope>test</scope> </dependency>

然后配合PostProcessor调用链：

import static org.springframework.security.test.web.servlet.request.SecurityMockMvcRequestPostProcessors.csrf; import static org.springframework.security.test.web.servlet.request.SecurityMockMvcRequestPostProcessors.user; mockMvc.perform(post("/api/users") .with(csrf()) .with(user("tester").roles("ADMIN")) .contentType(MediaType.APPLICATION_JSON) .content(json)) .andExpect(status().isCreated());

with(csrf())是给POST请求补充CSRF Token，with(user("tester").roles(...))是伪造一个已登录用户。如果你用的是JWT、OAuth2这类自定义安全方案，需要另外配置对应的用户解析器。addFilters = false这个方案虽然方便，但会让测试绕开真实请求链路，我建议只把它当临时应急手段，不应该灌满整个测试仓库。

5.3 中文、日期与类型转换，这些边界条件最容易炸

MockMvc默认字符集是UTF-8，多数情况下中文没有乱码问题，但如果你遇到返回JSON里的中文在断言时对不上，第一反应应该是检查响应编码。在请求构造器上强制指定编码可以排除干扰：

mockMvc.perform(post("/api/users/form") .characterEncoding(StandardCharsets.UTF_8) .contentType(MediaType.APPLICATION_FORM_URLENCODED) .param("username", "孙七"));

日期字段是另一个高频雷区。如果你在测试里自己new了一个ObjectMapper，然后序列化一个含有LocalDateTime的User对象，很有可能会报InvalidDefinitionException，提示Java 8 date/time typejava.time.LocalDateTimenot supported by default。原因是这个ObjectMapper没有注册jackson.datatype.jsr310模块。而如果你直接@Autowired Spring Boot管理的ObjectMapper，它默认就带了JavaTimeModule，并且还会遵循application.yml里的spring.jackson配置。所以我的建议是：测试代码里序列化和反序列化对象，都用Spring容器里的ObjectMapper，不要自己new。

类型转换边界也值得专门写用例。比如GET接口里param("age", "abc")，Spring在把字符串转换为Integer时会失败，接口返回400，这属于正常的参数校验边界；如果你的接口在参数不合法时返回了500，就说明Controller缺少必要的容错或全局异常处理。MockMvc很适合把这些边界条件沉淀下来，作为接口健壮性的回归基线。

5.4 与Postman/curl的分工和一个小工具封装

我们团队现在的工作流是：接口调试和联调用Postman，接口回归靠MockMvc。Postman的优势是即点即用、能直观看到响应体，适合开发阶段快速验证；MockMvc的优势是随代码走、能进CI、每次mvn test都能跑。两者不是替代关系，而是不同阶段的不同工具。

MockMvc测试写多了之后，你会发现很多POST用例就是"对象转JSON、POST、断言"。这部分完全可以封装成一个私有方法，减少重复代码：

private ResultActions postJson(String uri, Object body) throws Exception { return mockMvc.perform(post(uri) .contentType(MediaType.APPLICATION_JSON) .content(objectMapper.writeValueAsString(body))); }

之后写用例就变成一行：

postJson("/api/users/import", users) .andExpect(status().isOk()) .andExpect(jsonPath("$.length()").value(2));

这套封装我用了很久，是我觉得MockMvc测试里性价比最高的提效手段。它把最容易写错的contentType和content组合固定住了，新人接手代码时也不容易再掉进参数进不了Controller的坑。如果你团队里MockMvc测试的代码量已经很多，还可以考虑在此基础上封装断言工具，把"成功响应"和"指定code响应"的通用结构统一断言，这样接口返回结构的演进也会被测试及时感知到。