企业官网建设流程全解析

先说说我自己最常遇到的一个场景：接口改完，项目跑起来，浏览器里或者Postman上点一下，看返回结果正常就准备提交。结果上线没两天，某个边界条件被触发，逻辑直接炸了，最后定位半天发现是Service层一个分支没处理。这种靠“手动点一遍”来验证的方式，覆盖的路径太有限，而且每次改动都要重复来一遍，时间全花在启动项目上了。SpringBoot单元测试解决的正是这个问题——在不需要启动完整应用的情况下，把Controller、Service、Repository各个分层的行为验证清楚，让每次代码改动都有即时反馈。

这次我把一个真实的SpringBoot项目里写单元测试的完整过程、方案取舍和踩过的坑整理出来，包含可直接复制改用的代码示例、覆盖率配置和常见问题的排查思路。适合刚开始给项目补测试的同学，也适合已经在写但觉得测试“又慢又脆”的人参考。内容围绕JUnit 5、Mockito、Spring Boot Test等主流组件展开，尽量把每个选择背后的原因也讲清楚。

1. 项目概述：SpringBoot单元测试到底在测什么

1.1 这次演示项目的结构与范围

为了不让例子飘在空中，我准备了一个典型的用户管理模块，包含Controller、Service、Repository三层，结构如下：

src/main/java/com/example/demo ├── DemoApplication.java ├── controller │ └── UserController.java ├── service │ ├── UserService.java │ └── UserNotFoundException.java ├── repository │ └── UserRepository.java └── entity └── User.java

业务规则比较简单：支持按ID查询用户、按邮箱查询用户、创建新用户时校验邮箱是否重复，以及删除不存在的用户时抛出明确异常。这个体量刚好能把分层测试的核心问题都覆盖到，又不至于被复杂业务干扰。实际项目里无论代码再多，测试思路是相通的——先搞清楚每一层到底负责什么，再决定对它测什么。

我选择这个模块还有一个原因：它包含了典型的“有外部依赖”场景。Controller依赖Service，Service依赖Repository，Repository依赖数据库。如果用一个 @SpringBootTest 把这些Bean全部加载起来再测，不仅启动慢，而且某个环节出问题时会很难判断到底是哪一层坏了。更合理的做法是：按层拆开，测哪一层就尽量隔离其他层。

1.2 单元测试解决什么问题，又解决不了什么问题

单元测试能解决的核心问题是“逻辑回归”。比如你改了一个金额计算规则、一个状态流转判断，如果没有测试，你只能手工去凑各种输入验证；有了测试，一个mvn test就能把所有历史场景重新跑一遍。尤其是Service层里那种复杂的if-else嵌套、状态机、边界条件判断，单元测试几乎是唯一能长期守住正确性的手段。

但单元测试也不是万能的。它验证的是“代码按照你写的逻辑运行”，而不是“你的逻辑是否正确满足了业务”。比如某个返佣比例本身就写错了，测试也会跟着错。所以说单元测试测的是实现与预期的一致，真正的业务正确性还需要集成测试、验收测试和人工评审来兜底。另外，单元测试对外部系统的真实连通性是无能为力的，比如第三方HTTP接口、数据库特殊语法、Redis集群状态，这些都要靠测试环境的集成测试去覆盖。

认清这一点很重要，能帮你合理分配精力。我见过不少团队把单元测试覆盖率当成唯一KPI，结果大家专门写一堆不痛不痒的测试去凑行数，真正的核心逻辑反而没人测。先想清楚“这段代码最重要的行为是什么”，再动手写测试，比盲目堆数量有价值得多。

1.3 测试金字塔怎么落到SpringBoot项目里

测试金字塔是一个经典的分层模型：底层是大量快速、廉价的单元测试；中间是数量适中的集成测试；顶层是少量端到端测试。落到SpringBoot项目里，我的习惯是：

• 单元测试：针对Service、工具类、领域对象，使用JUnit加Mockito，不启动Spring容器，毫秒级执行。
• 切片测试：Controller层用@WebMvcTest，Repository层用@DataJpaTest，只加载需要的Bean，秒级执行。
• 集成测试：关键链路用@SpringBootTest，配合Testcontainers启动真实数据库或消息队列，验证各层装配是否正确。

这样分层的最大好处是，绝大多数代码改动只需要跑底层测试，几秒钟就能得到反馈，不用每次都启动完整SpringBoot应用。只有涉及Bean装配、配置项变化时才需要跑集成测试。热词里经常看到有人问“SpringBoot测试太慢怎么办”，多半是把所有测试都写成了@SpringBootTest导致的结果。测试金字塔结构能在根上避免这个问题。

2. 方案选型与基础概念：先搞懂Spring Boot Test这一篮子东西

2.1 spring-boot-starter-test 给你装好了什么

SpringBoot项目里写测试，第一步就是在pom.xml引入测试依赖，通常长这样：

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

这个starter并不是一个单独的库，它是个“依赖集合”，帮你把测试需要的主流组件一次性拉进来，主要包括：

Spring Boot 3.x默认使用JUnit 5，所以测试类上的注解是org.junit.jupiter.api.Test，不是JUnit 4的org.junit.Test。如果项目里混着老代码，注意别引错包，否则测试方法根本不会执行。这里还容易踩一个坑：有人做完基础配置后跑mvn test，发现控制台提示“No tests found”，排查半天才发现是import写成了JUnit 4的注解，而项目里又没有引入JUnit Vintage兼容包，测试自然不会被识别。

关于版本，我之前建议直接沿用spring-boot-starter-parent管理的版本，不要手动指定JUnit或Mockito的版本号。Spring Boot版本升级时，这些测试库往往会同步调整，比如Spring Boot 3.4开始@MockBean就被标记为废弃，推荐用新的@MockitoBean。如果你强行锁旧版本，升级时容易出现各种莫名其妙的问题，这部分我会在后面的避坑章节展开。

2.2 三种测试写法的取舍：纯Mock、切片测试、全量上下文

SpringBoot的测试写法看着花样多，本质上就是三种路线，对应不同的验证粒度和启动成本。

第一种是纯Mockito测试。测试类和Spring容器完全无关，手写new对象，用@Mock创建依赖，@InjectMocks把Mock注入被测类。Service层测试我基本都用这种方式，执行速度最快，也不依赖环境。缺点是它验证不了注解是否生效、Bean是否装配正确，比如你漏了@Transactional导致事务没生效，这种测试是发现不了的。

第二种是切片测试。用@WebMvcTest、@DataJpaTest这类注解只加载Web层或数据访问层相关的Bean。Spring Boot Test提供了很多这种“切片注解”，思路是把启动成本降到最低又能验证框架层的整合逻辑。比如@WebMvcTest会帮你配置好MockMvc、消息转换器、异常处理器，但不会加载Service和Repository。这个路线的性价比很高，我强烈建议引入到日常开发里。

第三种是全量集成测试。@SpringBootTest会加载完整的ApplicationContext，配合@AutoConfigureMockMvc可以发起完整HTTP请求。这种测试最接近真实运行情况，但启动速度慢，且依赖的外部资源多，适合验证关键链路，不该当成所有测试的默认选择。很多团队测试耗时从几秒恶化到十几分钟，就是因为在第三种路线上用力过猛。

2.3 @SpringBootTest 的分层启动与配置分离

如果确实需要写@SpringBootTest，一定要学会给测试单独做配置。最常见的做法是在src/test/resources下放一个application-test.yml，然后用@ActiveProfiles("test")激活：

spring: datasource: url: jdbc:h2:mem:testdb;DB_CLOSE_DELAY=-1 driver-class-name: org.h2.Driver username: sa password: jpa: hibernate: ddl-auto: create-drop

这样测试跑的时候用的是内存H2数据库，不会碰到开发库或生产库的数据。有人会问，能不能直接用application.yml里的MySQL配置跑测试？能跑但非常危险，测试数据可能会写进真实开发库，而且一旦数据库连不上测试直接失败，影响所有人。我的原则是：测试环境永远用测试配置，跟开发环境彻底分开。

@SpringBootTest还支持指定webEnvironment属性，比如webEnvironment = RANDOM_PORT，会启动一个随机端口的真实Web服务器，配合TestRestTemplate或WebTestClient使用。如果只是需要通过MockMvc模拟HTTP调用，用默认的MOCK环境就可以，不必真占端口。

3. 实战演示：一步步写完Controller/Service/Repository测试

3.1 先看User模块代码结构与要测的点

动手写测试之前，我习惯先把“被测代码的关键行为”列出来。以UserService为例，它的核心行为有四个：按ID查到用户时返回用户对象，查不到时抛UserNotFoundException；按邮箱查用户时返回Optional；创建用户时如果邮箱已存在则抛出IllegalArgumentException；删除用户时若不存在同样抛异常。每一个行为都值得一个测试用例。

被测代码大概长这样：

@Service public class UserService { private final UserRepository userRepository; public UserService(UserRepository userRepository) { this.userRepository = userRepository; } @Transactional(readOnly = true) public User findById(Long id) { return userRepository.findById(id) .orElseThrow(() -> new UserNotFoundException("用户不存在, id=" + id)); } @Transactional(readOnly = true) public Optional<User> findByEmail(String email) { return userRepository.findByEmail(email); } @Transactional public User createUser(String name, String email) { if (userRepository.existsByEmail(email)) { throw new IllegalArgumentException("邮箱已被注册: " + email); } User user = new User(name, email); return userRepository.save(user); } @Transactional public void deleteUser(Long id) { if (!userRepository.existsById(id)) { throw new UserNotFoundException("用户不存在, id=" + id); } userRepository.deleteById(id); } }

可以看到UserService只依赖UserRepository，没有其他乱七八糟的东西。这就是构造函数注入的好处，后面测试时手动构造或者用@InjectMocks都很干净。如果这里用字段注入，测试时就得通过反射去塞Mock对象，体验很差。这也是为什么我强烈推荐Spring团队现在主推的构造函数注入。

3.2 Controller层：用MockMvc写出接口行为验证

Controller层的测试目标是“HTTP请求进来后，参数绑定、路径映射、状态码、响应体结构是否正确”。这里用@WebMvcTest只加载Web层，UserService用一个Mock替身顶上。

@WebMvcTest(UserController.class) class UserControllerTest { @Autowired private MockMvc mockMvc; @MockitoBean private UserService userService; @Test void getUserById_shouldReturnUser_whenUserExists() throws Exception { User user = new User(1L, "zhangsan", "zhangsan@example.com"); given(userService.findById(1L)).willReturn(user); mockMvc.perform(get("/users/{id}", 1L)) .andExpect(status().isOk()) .andExpect(jsonPath("$.id").value(1L)) .andExpect(jsonPath("$.name").value("zhangsan")) .andExpect(jsonPath("$.email").value("zhangsan@example.com")); } @Test void getUserById_shouldReturn404_whenUserNotFound() throws Exception { given(userService.findById(999L)) .willThrow(new UserNotFoundException("用户不存在, id=999")); mockMvc.perform(get("/users/{id}", 999L)) .andExpect(status().isNotFound()); } }

这个测试里有几个细节值得说。@WebMvcTest会自动扫描所有@ControllerAdvice，所以UserNotFoundException经过全局异常处理器转换成404响应。如果没有写全局异常处理，那么Service层抛出的异常会变成500，这个问题在测试里一眼就能暴露出来。MockMvc的jsonPath支持用类似JSONPath的语法检查响应体字段，比把整个JSON转成字符串去contains要可靠得多。

注意：@WebMvcTest只加载Controller、ControllerAdvice、过滤器等Web相关Bean，不会加载@Service和@Repository。如果你在测试里发现UserService为null，说明你忘了声明@MockitoBean或@MockBean。

3.3 Service层：用Mockito把外部依赖全部打桩

Service层的核心测试我几乎不用Spring容器，直接用JUnit 5 + Mockito。这样测试类没有容器启动负担，跑起来是毫秒级。测试代码如下：

@ExtendWith(MockitoExtension.class) class UserServiceTest { @Mock private UserRepository userRepository; @InjectMocks private UserService userService; @Test void createUser_shouldSaveUser_whenEmailNotExists() { given(userRepository.existsByEmail("new@example.com")).willReturn(false); given(userRepository.save(any(User.class))) .willAnswer(invocation -> invocation.getArgument(0)); User result = userService.createUser("lisi", "new@example.com"); assertThat(result.getName()).isEqualTo("lisi"); assertThat(result.getEmail()).isEqualTo("new@example.com"); then(userRepository).should().save(any(User.class)); } @Test void createUser_shouldThrow_whenEmailExists() { given(userRepository.existsByEmail("dup@example.com")).willReturn(true); assertThatThrownBy(() -> userService.createUser("wangwu", "dup@example.com")) .isInstanceOf(IllegalArgumentException.class) .hasMessageContaining("邮箱已被注册"); } @Test void findById_shouldThrow_whenUserNotFound() { given(userRepository.findById(100L)).willReturn(Optional.empty()); assertThatThrownBy(() -> userService.findById(100L)) .isInstanceOf(UserNotFoundException.class) .hasMessageContaining("100"); } }

注意几个关键点。@ExtendWith(MockitoExtension.class)是Mockito集成JUnit 5的入口，有了它@Mock和@InjectMocks才能生效。Mockito的when写法我用的是BDD风格的given，读起来更像是“给定什么条件，就期望什么结果”，对中文团队来说语义更清晰。其实when和given底层是同一套API，选一种风格并保持一致就好。

这里还用到then(userRepository).should()，它来自Mockito的BDD验证，作用是确认某个方法确实被调用过。写它的时候要克制，别把每个Mock方法都verify一遍。一般只在“这个调用是业务副作用核心”时才验证，比如save、sendEmail、delete这些有对外影响的调用。像existsByEmail这种查询方法，测了结果就够了，再verify反而让测试变得啰嗦。

3.4 Repository层：用@DataJpaTest验证SQL映射

Repository层的测试需要真实数据库参与才能验证查询方法名和SQL映射是否正确。Spring Boot提供的@DataJpaTest会启用一个基于H2内存数据库的JPA环境，并且每个测试方法执行完自动回滚事务，不会相互污染。

@DataJpaTest class UserRepositoryTest { @Autowired private UserRepository userRepository; @Test void findByEmail_shouldReturnUser_whenExists() { User user = new User("test", "find@example.com"); userRepository.save(user); Optional<User> result = userRepository.findByEmail("find@example.com"); assertThat(result).isPresent(); assertThat(result.get().getEmail()).isEqualTo("find@example.com"); } @Test void existsByEmail_shouldReturnFalse_whenNotExists() { boolean exists = userRepository.existsByEmail("not-exist@example.com"); assertThat(exists).isFalse(); } }

@DataJpaTest默认只会扫描@Entity、Repository以及JPA相关配置，不会加载Controller和Service。它默认使用内嵌数据库替换你配置的真实数据源，前提是classpath下要有H2依赖。在pom.xml里加上这一段即可：

<dependency> <groupId>com.h2database</groupId> <artifactId>h2</artifactId> <scope>test</scope> </dependency>

如果项目里用了MySQL特有的JSON字段、自定义函数或者复杂原生查询，H2不一定完全兼容。这时候有两种选择：一种是用Testcontainers启动真实MySQL容器，测试最接近生产但环境依赖较重；另一种是只对简单CRUD跑@DataJpaTest，复杂SQL留给集成环境。我的经验是，大部分Spring Data JPA的派生查询在H2上都能验证，项目初期可以先靠H2，等SQL复杂到H2模拟不了再升级方案。

3.5 覆盖特殊异常分支与边界输入

很多人写测试只测“正常路径”和“一个异常路径”，这远远不够。真正让测试体现价值的是那些最容易回归出问题的边界条件，比如空字符串、null、超大ID、分页边界。以UserService的createUser为例，至少还要补这几个场景：

@Test void createUser_shouldRejectBlankName() { assertThatThrownBy(() -> userService.createUser(" ", "abc@example.com")) .isInstanceOf(IllegalArgumentException.class); } @Test void createUser_shouldRejectNullEmail() { assertThatThrownBy(() -> userService.createUser("zhangsan", null)) .isInstanceOf(IllegalArgumentException.class); }

当然这些校验最好放在Bean Validation层或者Service入口，但不管你放在哪一层，测试都要跟上。我习惯用“分支覆盖”的思路来检查测试是否完整：浏览一遍被测方法里所有if、else、catch、for，确保每个分支至少有一个用例走到。不需要纠结覆盖率数字是不是100%，但核心方法的每个分支必须走到，这比盲目追求总覆盖率更重要。

边界值测试还有一个额外好处：它逼着你把代码里的“隐含假设”显式化。比如某个排序逻辑默认输入不为null，一旦将来调用方传了null进来，测试会第一时间告诉你“你的假设被打破了”。

4. 覆盖率与质量门禁：让测试结果变成可执行的标准

4.1 JaCoCo：用报表看哪些行没测到

测试写没写够，不能光凭感觉，我一般用JaCoCo看覆盖率报告。在pom.xml里加入JaCoCo插件：

<plugin> <groupId>org.jacoco</groupId> <artifactId>jacoco-maven-plugin</artifactId> <version>0.8.12</version> <executions> <execution> <goals> <goal>prepare-agent</goal> </goals> </execution> <execution> <id>report</id> <phase>test</phase> <goals> <goal>report</goal> </goals> </execution> </executions> </plugin>

跑完mvn test之后，在target/site/jacoco/index.html里可以打开报告，看到每个类的行覆盖率和分支覆盖率。我一般重点关注Service层和工具类的分支覆盖率，Controller层因为有大量模板代码可以放低要求，Entity和DTO这类纯数据结构基本不要求覆盖。

JaCoCo报告会告诉你哪一行没有被执行，但不会告诉你“哪个分支的语义没测到”。比如一个if条件里的&&短路逻辑，JaCoCo可能只标了一部分。把JaCoCo报表和人工走查结合起来，才能对测试完整度有正确认知。覆盖率低说明肯定有盲区，覆盖率“看起来高”也不代表万无一失，尤其是那种为了凑覆盖率专门写一堆断言为空白的测试，毫无意义。

4.2 配置覆盖率规则，不让低质量测试进入主干

可执行的质量门禁需要把覆盖率阈值配置到构建里。JaCoCo支持在插件里配置rule，比如要求行覆盖率最低80%，核心包分支覆盖率最低70%，不达标时执行mvn verify直接构建失败：

<execution> <id>check</id> <goals> <goal>check</goal> </goals> <configuration> <rules> <rule> <element>BUNDLE</element> <limits> <limit> <counter>LINE</counter> <value>COVEREDRATIO</value> <minimum>0.80</minimum> </limit> </limits> </rule> </rules> </configuration> </execution>

把这个check挂在verify阶段之后，等于在CI流程里设置了一道闸门：新代码如果明显拉低覆盖率，流水线会直接红。不过阈值不能拍脑袋定死，我建议从一个相对保守的值开始，比如70%到80%，随着团队测试习惯建立再逐步提高。规则太严格会导致大家想方设法绕过覆盖，比如把逻辑塞进private方法或者干脆写空测试，反而破坏代码质量。

4.3 单元测试的命名规范与维护习惯

测试的命名直接决定你半年后再看它时能不能秒懂。我给团队定的规范是：方法名_场景_期望结果。比如getUserById_shouldReturn404_whenUserNotFound，一看就知道在测什么，不用点开代码再想半天。中文团队也可以用中文方法名，Java允许，比如按ID查用户_用户不存在时_返回404，实际效果更直观，只要团队统一就好。

测试代码同样是代码，要像生产代码一样评审。我见过太多项目里测试代码写成一次性的，条件写死、Mock一堆、断言全是isNotNull，跑是能跑但什么都证明不了。维护的时候更痛苦的是测试跟着实现一起无限改动，改一个方法签名可能要动十几个测试。要降低这种成本，测试应该尽量面向“行为”而不是“实现细节”。比如createUser这个用例，断言“保存成功且返回用户”就比“断言返回值里的id是多少”更稳定，因为后者即使在没有意义的情况下也会暴露内部细节。

另外还有一个实用习惯：跑测试时优先跑增量测试，而不是每次都全量回归。IDE里可以直接右键执行当前测试类，mvn命令可以用-Dtest=UserServiceTest只跑指定类。个人开发阶段用这种方式省时间，CI阶段再跑全量，兼顾效率和安全性。

5. 实操中踩过的坑与排查方法

5.1 测试慢到没法日常跑？先看看是不是没分层

很多团队遇到的第一个问题是“测试跑太久”，动辄几分钟起步。我排查过好几个案子，原因高度一致：核心测试类全都写着@SpringBootTest，甚至有的Service纯逻辑测试也把整个容器加载起来。一个测试类启动消耗三五秒，几十个测试类叠在一起就是几分钟，再加上有的测试还需要连数据库或消息队列，慢上加慢。

处理方式就是把第2章里讲到的三种写法铺开来：纯Service逻辑用@ExtendWith(MockitoExtension.class)，不碰Spring容器；Controller用@WebMvcTest，不用启动完整Web服务；只有跨层链路才考虑@SpringBootTest。改完后很多项目的测试执行时间能从十几分钟降到几十秒。如果测试里连JPA Repository都想绕过，却又把@SpringBootTest加上，那几乎等于自己给自己上刑。

5.2 版本太新引发的兼容问题：@MockBean怎么就废弃了

Spring Boot 3.4发布后，很多人升级完发现控制台打印了@MockBean的废弃警告，跑得通但心里发毛。实际上这是Spring官方在推动新注解@MockitoBean和@MockitoSpyBean，作用类似@MockBean，但底层整合的是Mockito的MockitoSession，生命周期管理更规范。升级到3.4以上的项目，新测试代码可以直接使用@MockitoBean：

@WebMvcTest(UserController.class) class UserControllerTest { @Autowired private MockMvc mockMvc; @MockitoBean private UserService userService; // ... }

Spring Boot版本太高时还可能遇到另一个问题：项目里用的旧版Maven Surefire Plugin不兼容当前JUnit Platform版本，导致测试既不报错也不执行，控制台只显示构建成功。看到这种情况别犹豫，先检查surefire版本是不是跟Spring Boot版本匹配，或者直接用spring-boot-starter-parent管理的默认版本。版本升级时多看release notes，尤其关注标记为deprecated的类和注解，能少踩很多坑。

5.3 Bean循环依赖导致测试无法启动

Spring Boot 2.6之后默认禁止Bean循环依赖，如果你的Service里出现A依赖B、B又依赖A的情况，项目启动会直接抛异常。平时主应用可能勉强能起，但到了测试阶段更容易暴露，因为测试加载的Bean范围不同，装配顺序可能跟启动时不一样。

我实际遇到过不止一次：开发环境Debug时项目能启动，但一跑集成测试立刻报循环依赖。原因往往是某些Bean按需懒加载，正常启动时没有触发到依赖闭合的那一环，而测试上下文启动时会去实例化更多Bean，循环依赖就现形了。解法不是去把spring.main.allow-circular-references设成true，那是掩耳盗铃。正确做法是用构造函数注入，并重新审视两个类之间的职责边界，把循环依赖拆掉。比如A依赖B的查询结果，B又需要A的回调，通常可以抽出一个领域服务或者事件机制来解决。

5.4 测试数据互相污染怎么办

测试数据污染是最容易埋雷的问题之一。你写了一个“查询用户”的测试，单独跑能过，跟其他测试一起跑就挂，多半是数据残留导致的。@DataJpaTest每个用例默认回滚，所以一般不会出问题；但如果你写了@SpringBootTest，又在测试方法里调用了真实数据库操作，框架不会自动回滚，数据就留下了。

处理方案按优先级排列：能用事务回滚的尽量给测试类加@Transactional，让每个测试方法结束自动回滚；不能回滚的场景（比如真实调用了外部接口、JPA之外写了原生SQL导致事务边界不同）就在@BeforeEach里清理相关表；再复杂一点可以用Testcontainers每次启动一个干净的数据库实例，彻底隔离。清理时注意外键依赖顺序，先删子表再删主表，不然会卡在外键约束上。内存数据库DB_CLOSE_DELAY这个参数也值得关注，它控制最后一个连接关闭后数据库是否立即销毁，测试多线程场景下设置不当会导致不同测试类看到同一个数据库状态。

5.5 测试里用了异步逻辑容易出现“假通过”

现代项目里多少都会用@Async、CompletableFuture、消息队列做异步处理。这种代码在测试里特别容易写出“假通过”的用例：主体方法执行完直接断言，异步逻辑可能还没跑完，测试偶尔绿、偶尔红，让人完全摸不着头脑。

针对异步测试我有一个判断顺序。如果异步逻辑非常简单，比如只是往线程池里提交了一个任务，那可以用CountDownLatch或Awaitility等待异步结果就绪再断言。如果异步逻辑很复杂，那更好的做法是把它拆出来单独测试，主体流程测试时用Mock去替代异步执行部分。以@Async方法为例，测试里最好显式等待一段时间或者直接同步调用底层逻辑，而不是赌线程调度一定够快。Awaitility是个好工具，它支持类似“最多等5秒，每100毫秒检查一次条件”的写法，比Thread.sleep硬等要可靠得多。

心得：写测试最忌讳的就是“能跑就行”。一个测试如果偶尔会挂、断言不明确、或者需要通过调整sleep时间去碰运气，那它就不是资产，而是负债。遇到这种用例应该立刻修，放任不管会让团队成员逐渐失去对测试的信任，最后整个测试套件形同虚设。

收尾：我这几年的一个真实体会

项目里的单元测试从零到有、从有到有效，最难的其实不是技术，而是转变把“写完代码去启动一遍”当作验证的习惯。我刚入行那几年也觉得测试麻烦，直到一个上线事故让我彻底改了思路——那次是一个状态判断的分支漏了处理，线上数据被改错，排查花了一整夜。后来我把当时的高危场景补成测试用例，从那以后每次改动只需要跑一下相关测试，心里就有底多了。

所以最后一个建议是：不用一上来就追求全局覆盖率数字，先把核心Service的异常分支、边界条件，和Controller的状态码这些最容易被回归破坏的点写出来。等团队跑测试变成习惯，再慢慢扩展。你最后会发现，写测试省下的调试时间，远比写测试本身花掉的时间多得多。