Java 写了好几年，单元测试这块我见过太多两种极端：一种是完全不写，全靠手工点页面验证；另一种是硬凑覆盖率，assert 写得跟没写一样，跑红了都不知道业务逻辑哪里断了。如果你正在从前者往后者过渡，或者已经写了些测试但总觉得不得劲，那这篇就是给你准备的。
这篇文章我会把 JUnit 5 从基础到实战一次性讲透，包括它的核心架构、常用注解、断言与假设、参数化测试、嵌套测试、动态测试，以及和 Mockito、Spring Boot 的集成方式。重点不是罗列 API，而是告诉你每个机制解决的是什么问题，什么场景下用它才是对的，哪些坑我替你踩过了，你就别再踩。
1. 为什么是 JUnit 5：它的架构变化解决了哪些真实痛点
先聊点背景。JUnit 5 不是 JUnit 4 的小版本升级，而是一次彻底的重写。它把整个体系拆分成了三个独立组件：JUnit Platform、JUnit Jupiter 和 JUnit Vintage。
Platform 是基础，它是 JVM 上启动测试框架的底座，负责发现测试、执行测试、汇总结果。Jupiter 是新的编程模型，就是我们平时写@Test、@BeforeEach这套注解的出处。Vintage 则是为了兼容 JUnit 3 和 4 的老测试代码，让旧项目能平滑迁移。
理解这个拆分很重要，因为它解决了一个实际工程问题：以前如果测试框架升级，整个项目的测试代码都要跟着改；现在测试逻辑写在 Jupiter 上，底层执行引擎是 Platform，升级时可以控粒度、控节奏。更重要的是，你可以在同一个项目里同时跑 JUnit 4 老测试和 JUnit 5 新测试，不需要一次性推倒重来。
从项目管理视角看，这套架构的价值也很直接——它把“写测试”和“跑测试”两个关注点解耦了。比如你想接入一个新的测试引擎，不用改业务测试代码，只改 Platform 层面的配置就行。对于接手老项目的人来说，这个渐进式迁移能力是实打实省时间的。
1.1 生命周期管理：每个注解背后都有一笔账
JUnit 5 的测试生命周期比 JUnit 4 严谨得多。核心注解是这几个：@BeforeAll、@BeforeEach、@Test、@AfterEach、@AfterAll。刚看会以为是换个名字，实际上语义和默认行为都有变化。
最典型的差异是@BeforeAll和@AfterAll。在 JUnit 4 里，这两个方法必须是 static；在 JUnit 5 里默认仍然要求 static，但如果测试类上加了@TestInstance(Lifecycle.PER_CLASS)，它们就能变成实例方法。这个改动对写集成测试特别友好——你可以在@BeforeAll里启动一个测试容器实例，在@AfterAll里关掉它，而不用靠 static 变量来回倒腾状态。
@BeforeEach和@AfterEach则对应 JUnit 4 的@Before和@After，每个测试方法执行前和后都会调用。这里有个细节：如果测试类有多层继承或嵌套结构，每个层级的@BeforeEach都会按父类到子类的顺序执行，@AfterEach则反过来。这个顺序如果不清楚，容易写出有隐藏依赖的测试。
我自己一般这么分配：@BeforeAll只做重量级的全局准备，比如连数据库、启动消息队列；@BeforeEach做轻量级的数据准备，比如初始化 Mock 对象、清空集合、设置默认参数。原则很简单——能复用就别重复，但复用要有边界，别让测试之间的状态串味。
1.2 新断言机制：失败信息本身就要有信息量
JUnit 5 对断言进行了大幅升级，不再只是简单的assertEquals。现在断言方法基本都支持最后一个参数传失败提示信息，这样测试挂了之后，日志里直接能看到业务上下文，而不是冷冰冰的 expected 和 actual。
我喜欢拿assertAll当典型例子。它接收一组断言，执行时会等所有断言都跑完再汇总报告。正常情况下，如果一个方法有多个验证点，第一个挂了后面的就不会跑；但assertAll会把你写的所有断言全部执行一遍，然后把所有失败信息一次性列出来。修 bug 的时候你能一次看到全部问题，不用修一个跑一次。
另一个被低估的是assertThrows。它接收一个异常类型和一个Executable函数式接口，如果函数没抛异常，测试直接失败；如果抛的类型不对，也会失败。用它的好处是你还可以顺便验证异常消息，不只是验异常类型。这就是需求里说的“知其所以然”——断言的粒度直接决定测试能反馈多少有效信息。
2. 写测试前的骨架设计：从需求到用例的拆解方法
很多人拿到需求第一反应就是去写实现，等实现写完了再补测试。这种顺序会导致测试写得极其痛苦，因为你潜意识里已经认为代码是对的，测试就会不自觉地去“证明”它是对的，而不是去“质疑”它。
换个思路：先用测试把需求框出来。这个过程叫测试先行设计，也是 TDD 的核心理念。你不需要一开始就 TDD，但至少在动手编码前，把测试用例从需求描述里拆出来。每个用例背后都是一个行为验证点，每个验证点都要回答三个问题：输入是什么、做了什么、输出是什么。
比如一个用户注册功能，需求是“手机号和密码必填，手机号格式校验，密码长度不能小于 8 位”。拆用例时就会得到：空手机号、空密码、非法手机号、短密码、正常输入、重复手机号、并发注册。每个用例就是一个测试方法，方法名直接用业务语义，比如shouldRejectUserWhenPhoneNumberIsMissing。这个方法名本身就是需求文档，以后维护代码任何人看测试名就知道这个类干了什么。
用例拆完之后，再考虑测试结构。如果一组用例共享一套准备逻辑，就用嵌套测试把它们组织在一起。JUnit 5 的@Nested注解允许在测试类内部再建内部类，每个内部类有自己的生命周期和准备逻辑，非常适合按场景分组。比如“注册用例”下可以拆“手机号校验”、“密码规则”、“验证码逻辑”三个内部类，互相不污染，跑起来又清晰。
2.1 分层设计：一个测试类到底测什么才算及格
一开始写测试容易陷入一个误区：给每个 Controller、Service、Mapper 都配一个测试类，写到哪算哪。结果 Service 里逻辑被覆盖了，但状态流转没人测；有的测试类只是把 getter setter 测了一遍，覆盖率看着高，实际价值很低。
我建议按测试目标来分层。Controller 层通常用MockMvc做接口层测试，关注的是 URL 路由、参数绑定、状态码和响应结构；Service 层用 Mockito 做单元测试，关注的是业务分支、异常处理、边界条件；Repository/Mapper 层做集成测试，关注 SQL 语句和数据库交互。每层测的东西不一样，测试的技术栈也不一样，混在一个类里会让定位失败变得很痛苦。
还有个容易忽略的点：DTO、VO 这类简单对象不要单独写测试类。它们只是数据载体，没有业务行为，测了只是凑行数。真正值得测的是那些有 if/else、循环、递归、异常处理的逻辑方法，以及对外部依赖的交互行为。
我自己的习惯是，给每个核心业务类建一个对应的测试类，测试类里按业务场景拆嵌套类，每个嵌套类只测一组相关行为。这样测试代码和业务代码在结构上保持对应，任何人接手都能快速定位“这个逻辑的测试在哪里”。
2.2 测试数据管理：写死常量还是动态生成，两者怎么选
测试数据这个事，看着简单，实际坑很多。最基础的做法是直接在测试方法里写死字符串、数字、对象，好处是直观，读测试就能看懂，坏处是一旦业务字段增加，每个测试方法都要去改。
我常用的做法是造“数据工厂”。在测试包下放一个专门的类，里面是各种业务对象的标准构造方法，叫UserFixture、OrderBuilder之类。把默认字段填充好，测试里需要特殊字段时再覆盖。这样核心数据只有一份定义，测试代码清爽，业务调整时也只需要改一个地方。
另一个问题是随机数据。有人喜欢用随机字符串来模拟输入，比如往名字字段里塞UUID.randomUUID().toString()。短期看确实省事，但随机意味着不可复现——测试挂了，想用同样的数据重跑一次却跑不出来，排查起来非常痛苦。除非有明确需求，否则不要用随机数据。真要测随机性，比如并发、排序、加密盐值，也要把随机种子固定住，保证每次跑出来的序列一致。
从需求出发做选择：如果你测的是校验逻辑，用边界值和非法值比标准值更有价值；如果你测的是业务计算，用一组已知输入对应一组已知输出，直接断言结果；如果你测的是异常链路，重点准备那些会触发异常的参数组合。总之，测试数据的核心目标是让行为可预测、可复现。
3. 参数化测试：一条测试代码跑十组数据
参数化测试是 JUnit 5 最实用的功能之一，它解决的核心问题是“同一套断言逻辑，换不同输入反复验证”。最直观的场景就是校验规则——手机号格式、密码强度、身份证合法性，这类逻辑往往有一堆边界值和非法值，用普通写法得复制粘贴一堆几乎一样的测试方法，而参数化测试用一套代码搞定。
JUnit 5 里参数化测试的核心是@ParameterizedTest注解配合各种@ValueSource、@MethodSource、@CsvSource、@EnumSource。不同的注解对应不同来源，选哪个取决于你的输入数据的结构和量级。
@ValueSource最简单，适合单参数场景，比如字符串、整数、枚举。@CsvSource适合多参数场景，直接用逗号分隔一行数据，特别适合表格型参数。@MethodSource最灵活，它可以返回一个Stream或集合，里面可以放复杂对象，适合多参数且包含对象构造的场景。
3.1 参数来源选择的经验法则
我的经验法则是：能用@CsvSource表达的线性数据，不要硬写成@MethodSource；但参数是复杂对象，或者参数之间有关联关系时，别为了省事硬往@CsvSource里塞，可读性会迅速下降。
@MethodSource的另一个优势是可以动态生成数据。比如你需要在运行时根据当前环境生成测试数据，或者大批量生成边界值组合，用静态方法返回Stream就能实现。要注意，这个方法必须是 static 的，除非测试类加了@TestInstance(Lifecycle.PER_CLASS)。
我在实际项目中比较常用的是@CsvSource，因为大多数校验类用例的参数都是二维表格结构：一个输入值，一个期望值。用 CSV 表示就是两列，阅读起来非常直观。比如测一个金额格式化方法，第一列是原始数字，第二列是格式化后的字符串，整个测试方法只要写断言逻辑，数据全在注解上，一行一个 case，挂掉之后失败信息直接告诉你哪组数据出的问题。
3.2 参数化测试与断言信息的配合技巧
参数化测试虽然省代码，但它有一个天然的痛点：失败了不好定位是哪组参数。如果@ValueSource里写了 20 个字符串，第 13 个挂了，控制台只会告诉你断言失败在哪个测试方法，不会自动告诉你具体是哪组数据。
解决办法有两个：一个是给断言加自定义提示信息，把参数拼进去；另一个是利用 JUnit 5 的@ParameterizedTest内置的参数占位符。
建议的写法是：在断言方法的 message 参数里拼入当前参数值。比如assertEquals(expected, actual, "当前手机号: " + phone + " 格式校验失败")。这样失败信息直接包含业务上下文，排查效率直接翻倍。另外，JUnit 5 还支持在测试方法里声明TestInfo参数来获取当前测试的相关信息，在复杂场景下也很实用。
从实际管理角度看，参数化测试不是越多越好。参数化测试的价值在于验证规则，不在于验证流程。如果一个测试用例依赖多个前序状态，比如先注册、再登录、再下单，那它不适合参数化，因为每个状态之间有关联顺序，硬参数化会让测试代码变成一团乱麻。
4. 嵌套测试：把复杂业务场景组织成树状结构
嵌套测试是我强烈推荐的功能，尤其当你的类逻辑复杂、测试用例多时，它能彻底改善测试代码的可读性。核心就是@Nested注解，它允许你在测试类中定义内部类，每个内部类可以有自己的生命周期方法和测试方法。
为什么要嵌套？因为很多业务类的测试用例天然可以分组。比如一个“订单服务”测试类，可以拆成创建订单、修改订单、取消订单、查询订单四个内部类，每个内部类只关注一个业务维度。跑测试时，IDE 和报告会以树状展示这些嵌套类，一眼就能看出哪个业务维度出问题了。
嵌套类还有一个隐性好处：生命周期隔离。每个嵌套类内部的@BeforeEach和@AfterEach只影响当前内部类的测试方法，不会影响外层和其他兄弟内部类。这意味着不同分组的准备逻辑完全隔离，不会因为埋点数据不同而互相干扰。
4.1 嵌套测试与共享状态的边界
嵌套测试看起来像分组工具，其实它还在逼你思考共享状态的边界。比如外层测试类有一个@BeforeEach用来初始化老订单数据，内部的“取消订单”分组需要在那个基础上再加一套“已支付”的状态准备，那就在内部类再写一个@BeforeEach。两层叠加执行，互不冲突，这是嵌套结构最舒服的地方。
要注意的是，JUnit 5 默认是一个测试方法一个实例，所以嵌套内部类之间的字段不能期望共享。如果你希望内部类之间共享重量级对象，比如数据库连接、Redis 连接，需要把它们设计成静态资源或者用@TestInstance(Lifecycle.PER_CLASS)配合静态生命周期。但我的建议是能不共享就别共享，测试之间越独立，排错越干净。
4.2 嵌套测试代码的组织范式
我常用的嵌套测试组织范式是这样的：外层类只写公共的生命周期方法，内部类里按场景进一步分层。外层@BeforeEach初始化最基础的 Mock 对象，内层@BeforeEach构造特定场景的数据。
拿一个支付服务测试类举例。外层类声明PaymentService和被 Mock 的PaymentGateway、TransactionRepository；内层“支付成功”里@BeforeEach设置网关返回成功响应，测试方法断言收到成功回执；“支付失败”里则设置网关抛异常或返回失败响应。整个类结构像一本书的目录，一个场景一个章节，调试时直接跳到对应章节看问题。
嵌套测试还有个衍生价值：它天然就是代码评审里的设计反馈。如果一个业务类的测试嵌套超过三层，通常说明业务类本身逻辑太杂，该考虑拆类了。测试结构倒逼代码结构，这种反向约束在实际项目中比代码规范有效得多。
5. 动态测试：优雅解决运行时才知道测试用例的情况
动态测试是 JUnit 5 另一个有代表性的特性，跟传统测试最大的区别是：测试用例不是写死在代码里的，而是在运行时生成出来的。核心是@TestFactory注解，配合 factory 方法返回DynamicTest集合或流。
什么时候需要动态测试？我举一个实际场景：你有一个方法，需要测试它在 100 个城市下的不同规则分支。这些城市可能是从配置文件或数据库里加载的，不同的城市对应不同的校验策略。如果你把 100 个城市写死在代码里，改配置就要改代码；但用动态测试，测试用例根据运行时数据自动生成，新增城市只改数据就行。
另一个典型场景是测一堆文件解析器。假设你的程序要支持 CSV、JSON、XML 三种格式，每种格式下有多个样例文件，动态测试可以直接遍历目录下所有样例文件，为每个文件生成一个DynamicTest。文件新增了，用例自动多出来；文件有问题，失败信息直接带上文件名，定位非常快。
5.1 动态测试的可读性和调试体验
动态测试有个需要提前接受的现实：IDE 里的展示效果不如普通测试那么直观，因为测试名是运行时生成的字符串。所以我会要求动态测试的 displayName 一定要带上具体场景标识，比如城市代码、文件名、业务规则。否则失败了你根本不知道是哪个用例挂了。
还有一个调试上的坑：动态测试在 IDE 里要么全部跑完，要么按工厂方法维度跑，你不能单独跑其中某个动态用例。对于偶尔需要单测某个用例的场景，这会有点难受。我的做法是在动态工厂方法里加一个 DEBUG 开关：手动指定只生成某一类子用例，方便本地跑；CI 环境下不加开关全量跑。
从使用频率看，动态测试不用滥用。普通业务逻辑能用参数化测试解决的，不要硬上动态测试；动态测试适合那种用例集合本身是动态变化的场景。如果你的测试用例是静态的，强行动态化只会增加识别成本，反而违背了让测试可读的初衷。
5.2 动态测试与参数化测试的协同边界
这几个概念经常被混着问，其实边界很清晰。参数化测试是把一组已知的静态参数反复喂给同一个测试方法，强调“同逻辑多输入”；动态测试是在运行时生成一组测试用例，强调“用例结构不固定”。
如果要用到一个动态生成的参数列表，比如从外部配置文件读取一批参数，那么参数化测试其实也能接得住，因为@MethodSource本身就支持在运行时返回动态参数流。这时候用参数化测试更合适，展示效果更好。动态测试真正不可替代的场景是：每个用例的执行逻辑本身就不同，比如不同城市走不同断言分支。
我一般按一句话判断：如果逻辑一样，参数不同，用参数化；如果逻辑也不同，只是它们有一组共通的驱动数据，用动态测试。如果你发现自己把一个动态测试里塞了好几个 if else 来区分不同场景，大概率是该拆成多个普通测试类了。
6. 测试同时执行：并行度配置与线程安全坑
测试执行速度在很多项目里是个被忽视的问题。几千个用例顺序跑跑十几分钟，CI 一次提交等这么久，基本等于没人愿意跑。JUnit 5 从 5.3 开始支持并行测试，但它是默认关闭的，需要显式配置。
开启并行有两条路径：一条是全局配置，在src/test/resources下建junit-platform.properties，设置junit.jupiter.execution.parallel.enabled=true以及parallel.mode.default=concurrent；另一条是类级别注解@Execution(ExecutionMode.CONCURRENT)，单独控制某个测试类是否并行执行。
这里要提醒一句：并行测试不是灵丹妙药，它是拿代码质量换速度。如果测试里有共享状态，比如静态变量、线程不安全的集合、共享文件，并行之后会出现偶发失败，而且这种失败极其难排查，因为重跑时可能又通过了。所以开启并行前，先保证测试之间尽量无状态，或者至少把共享对象设计成线程安全的。
6.1 并行策略配置实践
并行度有两层要管：一层是方法级，一层是类级。parallel.mode.default=concurrent表示类内的方法并行；如果再配一个parallel.mode.classes.default=concurrent，那么多个测试类也会并行跑。测试类并行的速度提升最明显，但资源竞争也更激烈，特别是涉及数据库、文件系统的时候，要格外小心。
我建议逐步开启。第一步先只开方法级并行，观察一段时间看有没有偶发失败；如果没有，再考虑类级并行。同时配合junit.jupiter.execution.parallel.config.strategy=fixed可以指定线程池大小，默认情况下 JUnit 会根据 CPU 核心数决定，也可以手动写的更保守一些。
另一个常用配置是junit.jupiter.execution.parallel.config.fixed.parallelism=8,这个值不是越大越好，要看你的测试里有没有外部依赖。如果大多数测试是纯单元测试，8 到 12 是比较稳妥的；如果很多测试要走数据库或远程调用，并行太多会造成连接池耗尽或超时，反而更慢。调这个参数，本质是在吞吐和稳定性之间找平衡点。
6.2 并行下的测试隔离设计
并行测试最理想的形态是完全无共享。但现实中，比如测试要访问同一个测试数据库，这时不能真的无共享，得让每个测试分摊到不同的数据空间。一种做法是每个测试类用不同的 schema，另一种是每次测试前清理库表数据。需要根据项目基础设施条件来选。
我遇到过并行跑挂的场景，最后定位到是多个测试类同时往同一个表里插数据，外键约束互相干扰。解决方案是在并行模式下禁止多个测试类同时操作同一组表，做法有两种：一是在共享数据类上加@Isolated注解，让 JUnit 让这些测试单独跑；二是把这些测试调整到非并行的测试组里，用一个独立的执行阶段跑。千万别为提速让数据互相踩，偶发失败会浪费大量排查时间。
最后提醒：并行测试跑挂了先别慌，第一反应不是改业务代码，而是把并行开关关掉，或者把相关类切成非并行，然后复跑看是否稳定。如果关掉并行就稳定，那问题大概率出在测试代码的共享状态或资源竞争上，而不是业务逻辑本身。
7. 与 Mockito 集成：模拟外部依赖的关键细节
单元测试的精髓在于隔离。一个方法依赖另一个服务、一个第三方 API、一个数据库 Mapper，如果我们真实调用它们，测试就不再是“单元”了，而是退化成集成测试。Mockito 就是用来在单元测试中替代这些真实依赖的。
JUnit 5 下用 Mockito 有两种方式。最省事的是@ExtendWith(MockitoExtension.class)加@Mock注解，让 Mockito 负责创建和管理 Mock 对象。另一种是在每个测试方法里手动Mockito.mock(...)，适合要做复杂构造或者 Mock 对象只在个别方法里用的场景。
@Mock配合@InjectMocks是很多项目的主流玩法。@InjectMocks会把当前测试类里已经创建的 Mock 对象，通过构造器、setter 或字段反射注入到被测对象里。用这个组合，测试代码会简洁很多，但要注意：如果被测对象的依赖是通过构造器注入的，尽量保证构造器只有一个，否则 Mockito 的注入策略可能选错构造器，引发难以察觉的空指针。
7.1 打桩与验证的边界
Mock 对象有两个核心操作：打桩和验证。打桩用when(mock.method(args)).thenReturn(result)，意思是“当这个方法被用这些参数调用时，返回这个结果”；验证用verify(mock).method(args)，意思是“确认这个方法确实被调用过，且使用了这些参数”。
新手最常见的问题是：只打桩，不验证。这样测试只验证了“被测方法在 Mock 存在时不会报错”，但没验证“被测方法是否真的正确调用了外部依赖”。反过来，只验证不打桩，Mock 默认返回空值，被测方法的逻辑走到依赖返回值的分支时会因为空值走偏。
正确的姿势是：先打桩定义外部依赖的行为，再执行被测方法，然后用assertEquals验证返回值或状态变化，最后用verify验证关键的外部交互是否发生。四个步骤一个都不许少。特别是在写 Service 层测试时，verify往往比assertEquals更能暴露逻辑错误。
7.2 Mock 静态方法的注意点
Mockito 从 3.4 开始支持 Mock 静态方法，但要用Mockito.mockStatic()包一层，并且需要在 try-with-resources 块中执行。这个能力在某些场景很有用，比如工具类里的静态方法、日期获取、随机数生成，但要谨慎使用。
静态方法 Mock 的坑在于作用域是全局的。即使在单线程测试下，如果mockStatic的锁没被释放，会影响同 JVM 后面的测试。正确写法是：
try (MockedStatic<Util> mocked = Mockito.mockStatic(Util.class)) { mocked.when(() -> Util.getCurrentTime()).thenReturn(fixedTime); // 执行被测逻辑与断言 }从设计角度看，能不 Mock 静态方法就别 Mock，静态方法本质上是硬编码依赖，Mock 它只是在掩盖设计的脆弱。如果代码里大量依赖静态方法，优先考虑把静态逻辑改成实例方法再测，长期来看对可测试性提升更健康。
8. 与 Spring Boot 测试集成：单元与集成的分界线
Spring Boot 项目里写测试，最常见的场景是@SpringBootTest。它会把整个应用上下文拉起来，所有 Bean 都会实例化、注入。这个方式用来做冒烟测试和集成测试没问题，但如果你每个 Service 层测试都这么写，那测试就不是单元测试了，而是一堆重量级集成测试。
我建议的分界线是：测试的目的是验证单个类的行为逻辑，用纯 JUnit + Mockito；测试的目的是验证 Spring 容器装配是否正确、Bean 之间的依赖是否匹配、配置是否生效，才用@SpringBootTest。前者跑得快，毫秒级；后者秒级甚至十秒级，不适合频繁跑。
实际经验里，一个项目的单元测试应该占 80% 以上，集成测试只覆盖关键的容器装配和外部依赖交互。如果发现单元测试也要启动 Spring，八成是代码的依赖注入设计有问题，比如硬编码了 Bean 访问、直接用ApplicationContext拿对象，或者依赖太多了。
8.1 切片测试：把 Spring 上下文裁剪成小块
Spring Boot 提供了切片测试，比如@WebMvcTest、@DataJpaTest、@JsonTest，它们只会拉起所需的切片上下文，比@SpringBootTest轻量得多。@WebMvcTest只初始化 MVC 相关 Bean，适合 Controller 层测试；@DataJpaTest只初始化 JPA 相关组件，适合 Repository 层测试。
切片测试的引入其实是对测试职责的进一步细分。Controller 测试关注的是 HTTP 映射和参数绑定，不需要完整的 Service 逻辑，就可以用@MockBean把 Service 层模拟掉；Repository 测试关注的是 SQL 和实体映射，可以用真实的内存数据库，比如 H2，跑一个轻量级持久化场景。
要注意的是切片测试和完整上下文测试之间的差异可能造成“假绿”。比如@WebMvcTest里你 Mock 了 Service，但没 Mock 到配置类里加载的过滤器或拦截器，导致有些请求路径在完整上下文能走到，切片测试却走不到。所以切片测试适合做 Controller 层的基础验证，线路上略过的那部分还得靠集成测试补。
8.2 集成测试里的数据管理与回滚策略
集成测试需要真实数据库交互，但数据不能污染开发或生产环境。常见方案有两个：一是测试用独立库，配置指向测试专用数据源；二是用事务回滚，也就是@Transactional注解加在测试类或方法上，测试结束自动回滚。
@Transactional的测试回滚策略很好用，但要注意它只能回滚当前线程的事务。如果被测代码内部开启了新事务，比如用REQUIRES_NEW传播级别，这部分操作就不会跟着回滚。遇到这种情况，要么用代码里带的补偿机制手动清理，要么设计测试数据时故意避开这种路径。
另外一个常见问题：测试数据准备和清理。如果集成测试需要准备一批业务数据，比如用户、订单、商品，不要逐条save()硬插。可以在测试基类里准备一套通用数据集，或者在表结构设计阶段就规划好测试专用数据标识，清理时按标识删除。这样能保证每次跑完环境是干净的，重复跑稳定不出错。
写到这里，我把 JUnit 5 从架构到实战、从单元测试到 Spring 集成的核心内容都过了一遍。最后说点实际的：工具永远只是手段，测试的价值在于它能不能让你的代码在改动后快速建立信心。与其追逐覆盖率数字，不如把重点放在“哪些行为验证了、哪些分支没走到”。等你把 JUnit 5 这套机制用得顺手了，你会发现测试不是负担，而是最好的文档和最快的反馈通道。
