企业官网建设流程全解析

SpringBoot的测试代码，是我在项目里最坚持要求团队必须写的东西。很多人一听到“SpringBoot Test”第一反应就是加个@SpringBootTest注解，然后启动整个Spring容器跑一次，能过就万事大吉。但这种用法恰恰把SpringBoot测试体系里最值钱的部分浪费掉了。这套东西的核心，不是"能跑"或者"能启动"，而是通过自动装配和切面化的测试配置，让你在几秒钟之内完成对某一个具体模块的验证，同时还能保证不依赖真实的外部中间件。

我自己经历过一个项目，把MinIO、ActiveMQ、Kettle全塞进了一个SpringBoot工程，集成测试一启动，光连这些外部服务就要等二三十秒，还动不动就连不上导致全红。后来我把测试体系重新梳理了一遍，按分层思路把切片测试和Mock替换用起来，mvn clean test从"漫长且随机失败"变成了"稳定且秒级完成"。这篇文章就是想把SpringBoot测试从依赖、原理、注解到实战和排坑，完整地讲清楚。无论你是刚用IDEA创建第一个SpringBoot项目的新手，还是已经写了两三年业务代码但没认真研究过测试套件的开发，这篇都适合你静下心读一遍。

1. 测试这件事，SpringBoot到底帮你做了多少

1.1 从测试金字塔说起：你缺的不是测试注解，是分层思路

很多人把"测试"简单理解为"启动整个应用，然后用HTTP请求调一遍接口"，这其实属于系统测试或端到端测试。这种测试不是不能写，而是代价太高：每次都要完整加载ApplicationContext、建立数据库连接、启动Redis，一旦环境有一点差异，测试结果就跟着飘。所以业界普遍提倡测试金字塔——底层是大量的单元测试，中间是集成测试，顶层才是端到端测试。

SpringBoot Test体系恰恰是为这个金字塔设计的。它不是让你只写一种测试，而是给了你一整套按需加载的机制：

• 测Service层的逻辑，不需要HTTP容器，用普通单元测试加@MockitoBean把外部依赖替换掉；
• 测Controller层的参数校验和JSON序列化，用@WebMvcTest，只加载Controller相关的那几条Bean链路；
• 测Repository层的SQL和ORM映射，用@DataJpaTest，自动套上事务回滚和嵌入式数据库；
• 到最后才用@SpringBootTest做少量关键链路的冒烟验证。

我见过太多人一上来就@SpringBootTest一把梭，结果Service层的一个空指针异常反而被淹没在大量的Context加载日志里。先想清楚"你这次到底要验证什么"，再选对应的测试写法，这才是高效率的测试思路。

1.2 自动装配下的ApplicationContext：为什么你的测试会连带启动一堆Bean

要理解SpringBoot Test，必须先理解SpringBoot的自动装配原理。@SpringBootApplication本质上由三个注解组合而成：@SpringBootConfiguration提供配置能力，@EnableAutoConfiguration负责引入大量自动配置类，@ComponentScan负责扫描当前包及其子包下的Bean。

这套机制在启动应用时非常省事，但在测试时就是"甜蜜的负担"。当你写下@SpringBootTest，它会把上面这一整套流程几乎原样走一遍——DataSource会被创建，MyBatis或JPA的SqlSessionFactory会被初始化，RedisTemplate、KafkaTemplate等组件会尝试连接真实中间件，甚至springfox、springdoc这类文档组件也会跟着加载。

这就解释了一个经典现象：为什么你的项目加了MinIO、ActiveMQ之后，测试类开始频繁报错。不是你测试代码写得有问题，而是自动装配让测试上下文变重了，重到开始依赖真实的外部服务。SpringBoot官方给的解法有两个方向：一是用切片测试，缩小加载范围；二是用Mock把外部依赖在测试环境中替换成假的。这两个方向，后文我会逐个展开。

2. 环境准备：依赖、版本与基础配置

2.1 spring-boot-starter-test到底帮你引入了哪些库

在SpringBoot项目中引入测试能力，正常只需要一个依赖：

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

这个starter本身不写任何测试代码，它只是把一整套测试生态帮你打包进来。我用Maven的dependency:tree看过实际依赖，大致包含五类：

• JUnit 5全家桶：junit-jupiter-api、junit-jupiter-engine、junit-jupiter-params，分别负责API、执行引擎和参数化测试；
• AssertJ：流式断言库，写出来的断言更接近自然语言；
• Mockito：最常用的Mock框架，配合spring-boot-test支持的@MockitoBean使用；
• JSONAssert：对JSON串做结构化和字段级断言；
• Spring Test框架本身：spring-test提供TestContext框架、@Transactional测试回滚支持等。

如果你用的是SpringBoot 2.x早期版本，starter里默认还会带上JUnit 4的兼容依赖，甚至会让你在@Test导入时搞混org.junit.Test和org.junit.jupiter.api.Test。我建议从开始就统一用JUnit 5，也就是org.junit.jupiter.api包下的注解，避免后面升级时踩坑。

2.2 SpringBoot 3.x之后，测试API有哪些不兼容变化

很多老项目还在SpringBoot 2.x，网上搜到的测试教程也大部分基于旧版本。如果你接手的是一个SpringBoot 3.x项目，有四个变化必须知道，不然你把旧代码直接粘过来，编译都过不了：

这不仅仅是换个注解名的问题。SpringBoot 3基于Spring Framework 6，底层对Mock的整合方式也变了：@MockitoBean是在BeanFactory层面直接替换Bean定义，而不是像旧版本的@MockBean那样通过BeanPostProcessor在容器刷新后手动替换。理解这一点，你就明白为什么测试类的字段上标注的Mock对象，能够直接注入到被测试类里。

2.3 随机端口、Profile和配置文件隔离

SpringBoot的application.yml支持用---分隔多环境配置，常见的就有dev、test、prod三段。测试环境应该单独使用application-test.yml，里面配独立的数据库连接、以及关闭一些不必要的生产配置。

有两个配置细节我特别想强调。

第一是随机端口。如果你写的是@SpringBootTest(webEnvironment = WebEnvironment.RANDOM_PORT)，SpringBoot会为内嵌容器分配一个随机端口，你可以用@LocalServerPort拿到这个端口值：

@SpringBootTest(webEnvironment = SpringBootTest.WebEnvironment.RANDOM_PORT) class UserControllerIntegrationTest { @LocalServerPort private int port; }

这里有个大多数人踩过的坑：有的同学会在application-test.yml里手动写server.port: 8081，同时测试类又用RANDOM_PORT，结果发现测试里拿到的端口号和自己配置的不一致。原因在于RANDOM_PORT会把server.port设置为0，让系统自动分配，你在配置文件里写的8081会被覆盖掉。所以要么完全交给随机端口，要么明确自己管理端口，别混着来。

第二是@ActiveProfiles("test")。这个注解指定测试运行时激活哪个Profile。我习惯在每个测试类的类级别上都显式标注，哪怕只有一个test配置也要标，因为你没法保证CI机器的环境变量里不会多出一份奇怪的SPRING_PROFILES_ACTIVE。显式声明能避免"本地能跑、服务器上跑不过"的玄学问题。

3. 核心注解详解：从@SpringBootTest到切片测试

3.1 @SpringBootTest与webEnvironment的四种模式

@SpringBootTest是集成测试的门面，它的webEnvironment属性有四个选项，很多人从来没认真研究过它们的区别：

我常用的组合是：Controller层用MOCK加@AutoConfigureMockMvc，不需要占端口，速度快；少数需要验证真实容器行为的测试才用RANDOM_PORT。别一上来就给所有测试类加RANDOM_PORT，那等于每个测试都起一遍Tomcat，成倍拉长测试耗时。

3.2 切片测试：只加载你想测的那一层

切片测试是SpringBoot测试体系里最被低估的功能。它的核心思路是：只加载测试目标相关的Bean，跳过其他所有自动装配。

• @WebMvcTest：只加载@Controller、@ControllerAdvice、@JsonComponent、Filter、WebMvcConfigurer这些Web层组件，同时自动配置MockMvc。Service层的Bean不会被加载，如果你用到它们，就需要用@MockitoBean注入。
• @DataJpaTest：只加载@Entity和Repository接口，同时默认配置嵌入式数据库，并在每个测试方法结束后回滚事务。
• @JsonTest：只加载Jackson相关的序列化组件，适合单独测试JSON序列化和反序列化。
• @RestClientTest：专门测试RestTemplate或WebClient相关的客户端逻辑。

切片测试能极大提升测试速度，但有个副作用：因为上下文只加载了一部分Bean，如果你在测试代码里直接往被测试方法里注入了一个来自Service层的真实Bean，编译能过，运行时会因为找不到对应的Bean而报NoSuchBeanDefinitionException。解决方式就是Mock掉它。刚开始用切片测试的人，遇到这种报错会以为是自己注解没加对，其实只要想清楚"切片只切了哪一块"就明白了。

3.3 Mock体系：用假对象隔离外部依赖

SpringBoot测试的Mock体系，经过版本迭代现在分得非常清楚：

• @MockitoBean：创建Mock对象并替换容器中的同类型Bean。被测试类里注入的依赖，会被自动替换成这个Mock，所有调用默认返回默认值（null、false、0等），然后你再用when()去定义行为。
• @MockitoSpyBean：创建Spy对象，保留真实Bean的逻辑，只对指定方法做Mock。
• @Mock：单纯Mockito层面的Mock，不进入Spring容器，适合纯单元测试。

我举一个Service层测试的例子，这种写法我在项目中用得最多：

@ExtendWith(SpringExtension.class) class UserServiceTest { @Mock private UserRepository userRepository; @InjectMocks private UserService userService; @Test void getUserById_shouldReturnUserWhenExists() { User user = new User(); user.setId(1L); user.setName("张三"); when(userRepository.findById(1L)).thenReturn(Optional.of(user)); User result = userService.getUserById(1L); assertThat(result.getName()).isEqualTo("张三"); verify(userRepository).findById(1L); } }

注意这里用的是@ExtendWith(SpringExtension.class)配合@Mock和@InjectMocks，它不加载Spring容器，属于纯单元测试，执行速度毫秒级。当你的Service方法里依赖了三个Repository、一个外部API客户端时，这种写法才是常态。等到需要验证这整个Service和真实Repository之间的整合是否正常，才轮到@DataJpaTest和@SpringBootTest上场。

这里我必须提醒一个Mock陷阱：别把所有东西都Mock掉。如果Mock的粒度过大，比如把Service自己都Mock了，那测试就变成在测Mockito本身，完全失去意义。合理的粒度是"测谁就用真实的谁，只Mock它的外部协作方"。

3.4 @TestConfiguration：测试专用配置不会污染主上下文

测试中经常需要临时注入一些Bean，比如一个固定的Clock、一个测试专用的事务管理器。如果直接写在@Configuration类里，又会被@ComponentScan扫到，影响主应用程序的初始化。SpringBoot专门提供了@TestConfiguration来解决这个问题。

@TestConfiguration的本质是：被@SpringBootTest等注释加装的测试上下文识别，但不会被@ComponentScan扫描进生产包路径。你可以把它定义在测试类里作为静态内部类，也可以单独建一个测试配置类：

@TestConfiguration public class TestClockConfig { @Bean public Clock clock() { return Clock.fixed(Instant.parse("2024-01-01T00:00:00Z"), ZoneId.of("UTC")); } }

然后在测试类上引用：

@SpringBootTest(classes = {DemoApplication.class, TestClockConfig.class}) class OrderServiceTest { }

有一点要注意：@TestConfiguration里的@Bean方法返回的Bean，会覆盖掉同类型的常规Bean。如果你的业务代码中有多个同类型Bean依赖@Qualifier区分，测试配置里也一定要带上同样的@Qualifier，否则注入时会产生歧义。

4. 实战：从Service到Controller的完整测试代码

理论讲再多，不如直接看一套能跑的代码。我从一个常见的"用户管理"模块出发，把Service、Controller和Repository三层测试分别写一遍，并说明每个地方的选型理由。

4.1 Service层测试：打桩、验证、异常场景

假设UserService里有这样一个方法：注册新用户时，如果用户名已经存在，就抛异常。正常的业务逻辑大概是：

@Service public class UserService { private final UserRepository userRepository; public UserService(UserRepository userRepository) { this.userRepository = userRepository; } public User register(String username, String password) { if (userRepository.findByUsername(username).isPresent()) { throw new BusinessException("用户名已存在"); } User user = new User(); user.setUsername(username); user.setPassword(password); return userRepository.save(user); } }

测试时，我需要验证三件事：正常注册时返回了保存后的用户；用户名重复时抛出指定异常；保存操作确实被调用了一次。代码如下：

class UserServiceTest { @Mock private UserRepository userRepository; @InjectMocks private UserService userService; @Test void register_shouldSaveUserWhenUsernameNotExists() { User toSave = new User(); toSave.setUsername("alice"); toSave.setPassword("pass123"); when(userRepository.findByUsername("alice")).thenReturn(Optional.empty()); when(userRepository.save(any(User.class))).thenAnswer(invocation -> invocation.getArgument(0)); User result = userService.register("alice", "pass123"); assertThat(result.getUsername()).isEqualTo("alice"); verify(userRepository).save(any(User.class)); } @Test void register_shouldThrowExceptionWhenUsernameExists() { User existing = new User(); existing.setUsername("alice"); when(userRepository.findByUsername("alice")).thenReturn(Optional.of(existing)); assertThatThrownBy(() -> userService.register("alice", "123456")) .isInstanceOf(BusinessException.class) .hasMessageContaining("用户名已存在"); verify(userRepository, never()).save(any(User.class)); } }

两个细节值得展开：

• thenAnswer(invocation -> invocation.getArgument(0))的意思是"当调用save方法时，直接把传入的参数原样返回"。这是Mock Repository时最常见的写法之一，因为真实save方法会返回带ID的实体，而Mock不知道该怎么生成ID，你直接返回传入对象反而符合大部分Service层的使用习惯。
• verify(userRepository, never()).save(any(User.class))断言了"用户名已存在时，绝对不应该去调保存方法"。这种负面验证比只测异常抛没抛出来更有价值，它能防止未来有人改成"先保存后判断"引入脏数据。

4.2 Controller层测试：MockMvc模拟HTTP请求

Controller测试我推荐用@WebMvcTest加MockMvc，而不是启动整个容器。假设UserController是这样：

@RestController @RequestMapping("/users") public class UserController { private final UserService userService; public UserController(UserService userService) { this.userService = userService; } @GetMapping("/{id}") public ResponseEntity<User> getUser(@PathVariable Long id) { return ResponseEntity.ok(userService.getUserById(id)); } }

对应的测试：

@WebMvcTest(UserController.class) class UserControllerTest { @Autowired private MockMvc mockMvc; @MockitoBean private UserService userService; @Test void getUser_shouldReturnUserWhenServiceReturns() throws Exception { User user = new User(); user.setId(1L); user.setUsername("alice"); when(userService.getUserById(1L)).thenReturn(user); mockMvc.perform(get("/users/1")) .andExpect(status().isOk()) .andExpect(jsonPath("$.username").value("alice")) .andExpect(jsonPath("$.id").value(1)); } @Test void getUser_shouldReturn404WhenServiceThrows() throws Exception { when(userService.getUserById(99L)) .thenThrow(new UserNotFoundException("用户不存在")); mockMvc.perform(get("/users/99")) .andExpect(status().isNotFound()); } }

这里特别要解释一下@WebMvcTest(UserController.class)里的UserController.class参数。如果你不写这个参数，SpringBoot会尝试扫描所有@Controller，导致不符合预期的Controller也被加载进来。写上具体类之后，MockMvc的上下文就只包含指定的Controller，既避免加载过多Bean，也减少测试之间的互相干扰。

MockMvc的perform方法默认走的是Spring MVC内部调用，并不会真的发出HTTP请求，所以不需要占用端口，速度非常快。它的.andExpect()链式断言读起来也很直观：先断言状态码，再断言响应体里的JSON字段。

如果你要在测试里验证POST请求和请求体校验，还可以这样写：

mockMvc.perform(post("/users") .contentType(MediaType.APPLICATION_JSON) .content("{\"username\":\"\",\"password\":\"123\"}")) .andExpect(status().isBadRequest());

配合Controller上的@Valid注解，就能测试参数校验是否生效。

4.3 Repository层测试：事务回滚和数据源替换策略

Repository层测试，我更推荐@DataJpaTest而不是@SpringBootTest。它默认的行为包括：扫描@Entity和Repository接口、配置嵌入式数据库、给每个测试方法加事务并自动回滚。

先看代码：

@DataJpaTest class UserRepositoryTest { @Autowired private UserRepository userRepository; @Test void findByUsername_shouldReturnUserWhenExists() { User user = new User(); user.setUsername("bob"); user.setPassword("123"); userRepository.save(user); Optional<User> result = userRepository.findByUsername("bob"); assertThat(result).isPresent(); assertThat(result.get().getUsername()).isEqualTo("bob"); } }

这段代码跑起来后，测试方法结束时数据会自动回滚，不会污染数据库。但有一个前提要注意：默认的@DataJpaTest使用嵌入式数据库（H2）来替换你配置的真实数据源。如果你的Repository里写了只对MySQL方言有效的SQL（比如JSON_EXTRACT函数），在H2上执行就会报语法错误。

解决方案有两种。如果只是个别查询不兼容，可以用@AutoConfigureTestDatabase(replace = AutoConfigureTestDatabase.Replace.NONE)让测试直接使用你配置的真实数据库。这个选择比较重，需要保证测试库环境可用，而且回滚已经保护了数据安全，其实可接受。但如果你完全是MySQL重度用户，我更建议直接用Testcontainers跑一个真实的MySQL容器，代价是测试环境要装Docker。

我的经验是：团队项目里，Repository层测试用Testcontainers加真实数据库最稳；个人小项目用H2凑合一下也行，但碰到JSON字段、窗口函数时你会后悔。

4.4 参数化测试与AssertJ断言：JUnit5这些功能很实用

JUnit 5的@ParameterizedTest是我用了就回不去的一个功能。它允许你用不同参数运行同一个测试方法，很适合验证边界条件。比如测试一个校验用户名的方法：

class UsernameValidatorTest { @ParameterizedTest @ValueSource(strings = {"alice", "bob_123", "zhangsan"}) void shouldAcceptValidUsernames(String username) { assertThat(UsernameValidator.isValid(username)).isTrue(); } @ParameterizedTest @ValueSource(strings = {"", "a", "abc def", "toolongusername"}) void shouldRejectInvalidUsernames(String username) { assertThat(UsernameValidator.isValid(username)).isFalse(); } }

如果参数比较复杂，可以用@MethodSource，它返回一个Stream<Arguments>，可以在Java代码里自由组装参数对象。个人体会：参数化测试比写多个几乎重复的@Test方法更利于后续维护，改动验证规则时只需要改一处数据源。

AssertJ的断言库，我最常用的是这几个：

• assertThat(optional).isPresent()/.isEmpty()：专门对付Optional；
• assertThat(list).hasSize(3)/.containsExactly(a, b, c)：对集合做精确断言；
• assertThatThrownBy(() -> ...).isInstanceOf(...).hasMessageContaining(...)：异常断言。

尽量避免用assertTrue(list.size() == 3)这种写法，因为失败时你只看到expected: true but was: false，完全不知道集合到底长什么样。AssertJ会把实际值的内容打印出来，调试体验好很多。

5. 常见问题与排查经验

这部分是我最想写的。测试框架本身不难，难的是它和SpringBoot自动装配勾连在一起之后，会出现各种"本地能过、CI过不了""加上一个依赖就全挂"的诡异问题。

5.1 测试上下文加载慢：如何给测试"减重"

慢的根源几乎都是同一个：加载了太多的Bean。日志里如果出现大量Initializing Servlet 'dispatcherServlet'、Connecting to ...这种东西，说明你的测试正在启动一个接近生产环境的完整应用。

我的排查顺序是：

1. 把@SpringBootTest换成更精确的切片测试。Controller层用@WebMvcTest，Repository层用@DataJpaTest，纯Service逻辑直接用@Mock加@InjectMocks。
2. 检查测试类里是否引用了不必要的@Import或@Configuration，有些同学为了图方便把整个生产配置类import进来，相当于又把所有Bean拉回来了。
3. 如果确实需要完整上下文，考虑用Spring Test的上下文缓存机制。Spring的TestContext框架会缓存ApplicationContext，只要测试类的配置标识相同，多个测试类会复用同一个上下文。所以测试类之间尽量保持"配置相同"，比如都用同一个@ActiveProfiles("test")和同样的classes定义，不要每个类各写一套注解。
4. 日志级别调整到WARN，避免大量DEBUG日志拖慢执行。

5.2 端口冲突和随机端口使用不当

当你用RANDOM_PORT时，理论上不会出现端口冲突，因为系统随机分配。但如果你在配置里写了server.port=8081，又在测试里用了DEFINED_PORT，就会与本地正在运行的应用冲突。

更隐蔽的坑是：测试类里用了RANDOM_PORT，却同时通过@Value("${server.port}")去注入端口。RANDOM_PORT是通过环境变量机制覆盖的，@Value注入在Spring Boot 2.x早期版本有时拿到的还是配置里的原值，比如8081。这会导致你构造的请求URL指向一个错误端口。正确做法始终是用@LocalServerPort注解来注入端口，它由测试框架直接管理，能保证拿到的就是容器实际分配的那个随机端口。

5.3 测试数据污染：回滚为什么不生效

@DataJpaTest默认回滚，@SpringBootTest配合@Transactional也会回滚。但以下几种情况会让回滚失效：

• 测试方法里有异步操作。比如你调了一个@Async方法，事务已经提交了，子线程里的数据变更不在当前事务控制范围内，回滚管不到它。
• 使用了@Rollback(false)。有些同学为了调试方便手动关闭了回滚，结果测试跑了一次，库里多了一堆数据，第二次再跑就出现唯一键冲突。
• Repository层用了REQUIRES_NEW传播行为，它会把方法内的操作放到新事务中执行，此时外层回滚不会作用于新事务。

我的建议是：能回滚的测试一律依赖默认回滚；确实需要保留数据做联调的，单独放到一个专门的IntegrationTest包，名字上也标明"不清理数据"，并用@Tag("integration")标记，让它在CI里单独执行。

5.4 mvn clean test与IDE测试的差异：谁在坑你

我在公司遇到过很多次"IDEA里跑测试全绿，mvn clean test却失败"。这类问题99%不是测试代码写错了，而是Maven生命周期和IDE执行方式的差异。

常见原因有这么几个：

• 资源过滤问题。src/test/resources下的文件可能被Maven的resources插件按application.yml中的变量做替换，如果替换后YAML语法错了，测试上下文直接加载失败。
• 插件版本导致的环境差异。比如maven-surefire-plugin版本过旧，对JUnit 5的支持不完整，导致测试类没有被执行，或者执行时报No tests were executed。检查一下你的pom.xml里是否显式配置了surefire插件的<version>，至少用2.22.0以上的版本。
• 编码问题。Maven默认按项目编码编译，如果你在Windows下未设置project.build.sourceEncoding，测试类里的中文消息可能会出现乱码，导致hasMessageContaining("用户名已存在")断言失败。

我现在的习惯是：每改完一轮代码，在提交前一定跑一遍mvn clean test，以Maven的结果为准。IDEA里跑绿只是开发阶段的快速反馈，不能作为最终信心的来源。

5.5 接入中间件后的测试爆炸：MinIO、ActiveMQ、Kettle这些组件怎么处理

热搜词列表里有minio、activemq、kettle、jt808-server这类中间件，它们加进SpringBoot之后，最容易让测试崩掉。原因还是自动装配：这些组件的Starter一旦在classpath里，@SpringBootTest就会尝试创建对应的客户端Bean并连接真实服务。

处理方式分两步走。第一步，区分哪些组件在大部分单测里根本不需要。MinIO客户端、ActiveMQ的JmsTemplate、Kettle的ResourceRepository，这些在Controller测试和Service测试里基本都是依赖外部的"协作方"，直接@MockitoBean掉是最快的解法。例如：

@WebMvcTest(FileController.class) class FileControllerTest { @MockitoBean private MinioClient minioClient; @MockitoBean private FileService fileService; }

第二步，把真正需要中间件的测试隔离出来，放到集成测试包，用@Tag("integration")标记，并在CI配置里让这些测试连接专用的中间件实例，而不是在本机全量跑。

对于SpringDoc（Swagger）这类影响启动的组件，测试配置里直接关掉即可：

springdoc: api-docs: enabled: false swagger-ui: enabled: false

很多测试报错并不是业务代码的问题，而是Swagger的Bean初始化顺序和MockMvc冲突。关闭后测试干净很多。

6. 我常用的测试习惯与几个你可能会踩的细节

写了这么多年SpringBoot测试，最后整理几条我自己一直在用、也推荐团队遵守的习惯。

测试类命名直接决定你看日志的效率。我统一用"被测类名 + Test"命名Service和Repository测试，用"被测Controller名 + Test"命名Controller测试，集成测试加IntegrationTest后缀。这样CI报错时扫一眼类名就知道是哪一层挂了。

测试方法名的可读性同样重要。推荐业务行为_条件_期望结果的命名风格，比如register_shouldThrowExceptionWhenUsernameExists。英文下划线风格在JUnit报告里显示得很整齐，而且失败信息里能直接看出违反了什么约定。中文命名虽然合法，但我试过在Windows和Linux间切换时偶尔出现编码问题，不太建议。

关于测试执行顺序，默认情况下JUnit 5不保证方法执行顺序。理论上测试之间应该完全独立，不要依赖某个方法先跑。但现实是，当你要测JPA关联实体时，必须先把父实体插进去，子实体才能保存。遇到这种情况，我坚持用@Sql预处理数据，而不是靠测试方法执行顺序：

@Test @Sql(statements = "INSERT INTO department (id, name) VALUES (1, '研发部')") void createEmployee_shouldAssignToDepartment() { // ... }

@Sql和@SqlGroup是我在数据库相关测试里用得非常频繁的注解，它能在测试方法执行前统一准备数据，执行后清理，比在代码里手动save更清晰。

还有一个容易忽略的细节：测试类尽量别用@SpringBootTest(classes = DemoApplication.class)硬编码主类。如果后面工程结构调整，主类换了包路径，这行代码就得跟着改。可以换成使用@SpringBootTest不带classes属性，让测试框架自动从当前包路径向上搜索@SpringBootConfiguration。只有在多模块工程、主类不在测试类可扫描范围时，才需要显式指定。

最后再说说Mockito的when和doReturn选择。对void方法要用doThrow、doNothing、doAnswer这一套：

doThrow(new RuntimeException("发送失败")) .when(messageSender).send(anyString());

对非void方法，用when(...).thenReturn(...)更自然。但有一个特例：如果你Mock的方法内部会抛异常，而调用它时参数本身就可能触发NPE，推荐用doReturn系列，它不会提前解析参数。这个小技巧在Mock方法签名里有泛型或者参数复杂时特别有用。

SpringBoot Test这套东西，从掌握用法到形成自己的测试体系，中间差的不是文档阅读量，而是动手踩坑的积累。你现在再回头看项目里那些红了一大片的测试报告，大概率都能定位到是"加载范围太大""Mock粒度不对"或者"外部依赖没有隔离"这三类问题中的一种。把第五节的排查清单当成一份速查表，下次遇到问题一条条比对，比你重新搜一遍"SpringBoot Test 报错"要高效得多。