1. 先把这一章要解决的事说清楚JUnit实战系列走到第二章“核心功能”的下半段前面已经聊过断言怎么写、基础注解怎么用、参数化测试怎么入门这一章则把剩下几块关键能力串起来测试生命周期钩子、条件执行、重复测试、超时控制、动态测试以及测试用例的组织展示方式。说实话这些东西单个拎出来都不难难的是搞明白它们各自解决什么问题以及在一个真实项目里该怎么组合。这也是这篇内容最大的价值所在不是把JUnit的API念一遍而是把一个写过几年测试的人会怎么用这些功能摊开给你看。这篇适合两类读者。第一类是刚学完JUnit基础、准备把测试真正写进项目的人你需要知道除了断言之外JUnit还能怎么帮你管理准备、清理、跳过、限时这些测试周边的麻烦事。第二类是已经写了半年一年测试、但总觉得测试代码乱糟糟的人你缺的不是语法而是组织方式和踩坑经验。这篇不会有特别高深的理论但每一条都是我会在真实项目里反复用到的做法。1.1 为什么“核心功能”要分成两篇不是故意拖节奏而是JUnit 5的功能面确实宽。上一篇如果说是“怎么把断言写对”这一篇就是“怎么把测试用例组织好、控制好、跑得更聪明”。前者的核心是校验结果后者的核心是管理测试过程本身什么时候建数据、什么时候清理、哪些环境跑哪些用例、跑多久算失败、如何让测试名字变得可读。这两类知识的使用场景完全不同混在一起讲只会两头都讲不透。从学习路径上看我也建议你先把断言和参数化用熟再来碰生命周期和条件控制。因为后者往往要配合前者一起理解比如你知道了断言可以写在lambda里才能明白动态测试是什么你理解了参数化测试的边界数据设计才知道空值注解为什么那么顺手。所以这一篇不要急着硬记注解先把整体逻辑捋顺再回到代码里逐个试。1.2 这一章的实际学习思路我的建议是别把这一章当语法清单背。你完全可以只看一遍知道JUnit在生命周期、条件、超时、动态测试这些方向上有哪些“能力点”然后回到真实业务测试里去对照。比如你下次写一个需要连数据库的测试自然会想起BeforeEach和AfterEach怎么搭当你遇到某个测试只在Windows上能过自然会想起还有条件执行这回事。能力点先混个脸熟需要时能想起来比当场背下所有参数更有用。接下来我按自己常用的顺序把这几个功能逐个拆开讲中间会穿插我在项目里实际踩过的坑和一直在用的写法。内容会比官方文档啰嗦但每条都保证能落地。2. 生命周期钩子五个注解的默契生命周期这个词听起来很玄其实就是“测试方法前后能自动执行什么代码”。JUnit 5 提供了几个最常用的钩子BeforeAll、AfterAll、BeforeEach、AfterEach配合TestInstance可以把整个测试类的初始化、清理、状态管理安排得明明白白。理解它们各自的职责是写测试代码的骨架第一步。2.1 四个基本注解各管哪一段先看一张表把这几个注解的区别说明白注解执行时机典型场景BeforeAll当前测试类所有测试方法执行之前只执行一次启动数据库容器、创建连接、加载配置AfterAll当前测试类所有测试方法执行之后只执行一次关闭连接、销毁容器、清理全局资源BeforeEach每个测试方法执行之前都会执行一次构造被测对象、准备最小数据集、开启事务AfterEach每个测试方法执行之后都会执行一次清理临时数据、回滚事务、释放本地资源方法签名上要注意默认的PER_METHOD生命周期下BeforeAll和AfterAll必须是static方法。这一点在JUnit 4时代大家都很熟但切到JUnit 5后不少人会踩坑——因为JUnit 5允许你用TestInstance(Lifecycle.PER_CLASS)把整个测试类变成单实例模式这时BeforeAll就不需要static了。我会在后面单独展开。执行顺序上还有一个容易被忽略的细节BeforeEach的执行顺序是从父类到子类AfterEach则相反从子类到父类。这保证了当你有一个测试基类时基类里的公共前置条件会先准备好子类的特殊数据再补充上来清理时则先清理子类的数据再释放基类的资源不会出现“父类资源已经关了子类还在用”的问题。2.2 我真正会用的生命周期组合数据库测试这里直接给一个我在实际项目中反复使用的组合。比如要测一个订单服务测试类会连数据库TestInstance(TestInstance.Lifecycle.PER_CLASS) class OrderServiceTest { private DataSource dataSource; BeforeAll void initDataSource() { // 创建测试库连接池整个过程只做一次 dataSource createTestDataSource(); } AfterAll void closeDataSource() { // 释放连接池资源 closeQuietly(dataSource); } BeforeEach void openTransaction() { // 每个用例之前开启事务保证数据隔离 txManager.begin(); } AfterEach void rollbackTransaction() { // 每个用例结束直接回滚既不污染数据库也不用写一堆删除语句 txManager.rollback(); } Test void shouldCreateOrderWhenPayloadValid() { // 测试代码只关心业务逻辑 } }这里最值得说的一点是事务回滚的用法。如果你还在每个测试方法里手动insert数据、测试完再delete很快就会被数据残留搞疯。把BeforeEach和AfterEach搭配成“开事务回滚事务”是我在服务端测试里最推荐的方案能有效避免测试数据互相污染。我踩过的坑是BeforeAll里初始化了太多共享数据结果某些测试方法会修改这些共享数据导致后面的测试跑挂。解决方案是区分“全局只读资源”和“用例私有数据”连接池、容器、配置属于前者放进BeforeAll具体业务数据属于后者放BeforeEach里单独准备。这样既省了重复初始化的时间又不会因为数据被改而互相影响。2.3 测试实例生命周期PER_CLASS与PER_METHOD的取舍默认情况下JUnit 5为每个测试方法都创建一个新的测试类实例这叫PER_METHOD。这样测试方法之间不会共享成员变量好处是隔离性好坏处是两个非static的BeforeAll不能直接用每次new实例也有轻微开销。当你把注解写成TestInstance(TestInstance.Lifecycle.PER_CLASS)时整个测试类只创建一次实例所有测试方法共用同一个对象BeforeAll和AfterAll可以不再是static。我的建议是小测试类无所谓能保持默认就保持默认一旦遇到需要“每个测试方法都想用同一个mock对象或同一个连接”的场景再考虑PER_CLASS。不过用了PER_CLASS就必须格外小心成员变量的污染最好把可变状态控制在最小范围否则一个测试改了成员变量另一个测试就会跟着遭殃。我自己的惯例是PER_CLASS只用来放“创建成本高且逻辑上只读”的依赖比如服务对象、Mapper、DataSource业务数据一律不入成员变量。还有Nested嵌套测试的加入会让生命周期变得更有意思。一个简单的规则是每一层嵌套类自己的BeforeEach会先执行然后才执行外层类的BeforeEachAfterEach反过来先内层后外层。有了这个机制你可以在外层类准备好通用环境在内层类针对某一种业务场景补充特定数据测试结构会清晰很多。3. 条件执行只让该跑的测试跑起来条件执行是我非常喜欢的一组能力也是很多开发者容易用歪的地方。简单说JUnit 5允许你给测试方法或测试类挂上“运行条件”满足条件才跑不满足就直接显示跳过而不是失败。这对跨平台项目、依赖外部服务的测试、以及本地和CI环境差别很大的项目特别有用。3.1 基于操作系统和JVM版本的条件控制最常用的两个注解是EnabledOnOs和EnabledOnJre。比如某个测试依赖Windows下的文件路径分隔符或者某个JVM版本才有的行为可以这样写Test EnabledOnOs(OS.WINDOWS) void onlyRunsOnWindows() { // 检查Windows专属路径处理逻辑 } Test EnabledOnJre(JRE.JAVA_17) void onlyRunsOnJava17() { // 依赖Java 17新特性的行为 }对应还有DisabledOnOs和DisabledOnJre语义正好相反。写上这些注解后不符合条件的环境里测试桩会显示成“跳过”不会让整个构建变红。选择用“启用型”还是“禁用型”我个人的标准是默认环境应该跑的测试用EnabledOnXxx显式声明默认环境不需要跑的测试用DisabledOnXxx排除。比如大多数测试都基于Linux跑那就只在Linux上显示启用即可而不是每个非Linux环境都去写禁用。3.2 用系统属性和环境变量做细粒度开关有些条件的判断依据不是操作系统而是运行配置。JUnit 5为此提供了基于系统属性和环境变量的条件注解写法非常直白Test EnabledIfSystemProperty(named test.env, matches integration) void onlyRunsInIntegrationEnv() { // 只有显式传入 -Dtest.envintegration 时才执行 } Test EnabledIfEnvironmentVariable(named CI, matches true) void onlyRunsInCi() { // 只在持续集成环境里跑 }matches这里支持正则表达式所以你也可以写更复杂的匹配规则。从JUnit 5.7开始还支持EnabledIf和DisabledIf配合一个返回布尔值的静态方法使用EnabledIf(customCondition) Test void conditionalByCustomLogic() { // 只有 customCondition() 返回 true 才执行 } static boolean customCondition() { return isSpecialEnvironment(); }这套东西把“跳过测试”这件事变得很灵活但灵活也意味着容易被滥用。我在实际项目里见过最头疼的情况是某个人为了让失败测试通过构建直接在测试上加了Disabled(暂不修)结果这个测试永远不见天日。我的建议是条件执行应该服务于“环境差异”而不是掩盖“测试本身的失败”。暂时不修的测试要么明确留TODO并定期清理要么用Disabled并写明原因绝不要用环境条件来掩盖。3.3 我用条件执行的三种真实场景第一种是跨平台兼容。项目里同时支持Windows、macOS、Linux部分测试涉及文件系统、软链接、权限模型平台差异很大。我会把平台相关测试分组分别用EnabledOnOs标注确保每个平台上都只跑与本平台相关的用例同时避免其他平台误报。第二种是外部依赖只在CI环境存在。比如测试需要调用某个内部测试服务本地开发时不方便启动CI上有专门环境变量可以判断。这种情况用EnabledIfEnvironmentVariable就特别舒服本地自动跳过CI自动跑起来整个测试代码不需要为环境写if/else。第三种是本地开发时的慢测试。全量接口测试执行时间可能很长本地调试单测频率很高我会给耗时的端到端测试加一个自定义条件只有当系统属性包含-DrunSlowTeststrue时才执行。平时本地只跑快速单测提交到CI后跑全量。用条件而不是删测试既保证了覆盖率又不影响日常开发节奏。3.4 条件执行最容易被人骂滥用的地方条件执行最大的反模式就是“为了绿而绿”。比如某个测试在本地能过、CI上偶尔失败不去查原因直接加一行DisabledOnEnvVariable(named CI)这是把症状压下去了但把问题留给了以后的同事。第二个反模式是在同一个测试类里堆满各种条件导致别人根本分不清这个测试到底什幺时候会跑、什么时候会跳过维护成本比写测试本身还高。所以我在代码审查里会特别看条件注解的备注。如果条件后面不写任何说明我会直接要求补充如果写的是“为什么需要跳过”那我会认真评估是不是合理。条件注解不是终点它只是告诉JUnit“什么时候该跑”真正的价值判断还是得由人来做。4. 重复测试与参数化测试同一段逻辑的两种放大方式一个测试方法如果只跑一遍有些边界情况可能根本碰不到。JUnit 5提供了两种“放大”一个测试的机制一种是RepeatedTest把同一个测试重复执行多次另一种是ParameterizedTest用不同的参数多次执行同一个测试模板。它们看起来都像“跑很多次”但使用场景和背后的设计逻辑差别很大。4.1 RepeatedTest不是压测而是稳定性检查先看一个最简单的重复测试RepeatedTest(3) void retryThreeTimes() { // 同一段逻辑重复执行3次 }默认显示名是repetition 1 of 3这样的格式你也可以通过编程式测试名称自定义RepeatedTest(value 5, name {currentRepetition} / {totalRepetitions}) void customDisplayName(TestInfo testInfo) { // ... }这个功能最常见的误解是拿它当“性能测试”或者“压测”来用。其实RepeatedTest更合适的场景是验证代码的稳定性并发访问是否会出现偶发问题、线程安全类会不会在重复调用时暴露状态错乱、随机数相关逻辑有没有小概率异常。因为每次重复都是独立的测试实例调用所以重复之间如果存在共享数据污染很快就能暴露出来。但如果你想测的是“处理一万条数据需要多少秒”那应该用专门的性能测试工具而不是在单元测试里重复跑。4.2 参数化测试的几种数据来源参数化测试的核心是ParameterizedTest它必须配一个数据源注解。这里列一下最常用的几种数据源注解适用场景示例ValueSource简单的常量序列字符串、int、booleanCsvSource多字段参数表格行数据1,foo,2.5MethodSource需要动态生成或参数较复杂返回Stream/List的方法EnumSource枚举类型数据传入所有枚举值NullAndEmptySource边界值null和空字符串/空集合和ValueSource配合比如测试订单状态转换用CsvSource写起来非常舒服ParameterizedTest CsvSource({ CREATED, PAID, true, PAID, SHIPPED, true, CANCELLED, PAID, false }) void statusTransition(OrderStatus from, OrderStatus to, boolean expected) { Order order new Order(); order.setStatus(from); assertEquals(expected, order.canTransitTo(to)); }再比如校验字符串输入时空值空串常常是隐藏的坑ParameterizedTest NullAndEmptySource ValueSource(strings { , }) void blankStringShouldBeRejected(String input) { assertFalse(validator.isValid(input)); }这比手写五六个Test方法干净得多。需要注意的是使用MethodSource时数据源方法通常放在同一个类中且是static的在某些情况下也可以放外部工厂类里但需要额外指定方法引用的全限定名。4.3 选型建议优先参数化慎用重复我给项目定的一条内部规则是能参数化解决的问题就不要用RepeatedTest硬凑。参数化的价值在于“同一套逻辑用不同的数据覆盖不同的分支”重复测试的价值在于“同一个数据下多次运行看稳定性”。两者目标不同不能互相替代。举例来说判断一个字符串是否是合法手机号这就是典型的参数化合法号码、号码多一位少一位、包含字母、为空、全空格每条都是新数据而一个并发环境下多次往队列里加数据的测试更适合RepeatedTest。如果你在代码审查里看到有人用RepeatedTest(100)去测一个纯粹的函数计算那大概率是选错了工具。还有一点值得提醒参数化测试的代号要可读。参数化测试天然会把参数拼进测试报告如果参数含义不明确报告里只看到一行[1] args那基本等于没用。我习惯用ParameterizedTest的name属性定制展示例如name [{index}] {0} - {1}这样CI日志里一眼就能看出是哪组数据失败。5. 超时测试给测试上一道保险超时测试是我在线上业务项目里经常用、但在很多教程里看到讲得不够细的功能。JUnit 5用Timeout注解来限制一个测试的执行时间超过限制直接判失败。听起来很简单但它背后的执行模型、跟业务超时的区别、以及常见的误用方式都值得展开说。5.1 Timeout的执行模型和基本写法Timeout可以放在测试方法、测试工厂方法、测试模板或者整个测试类上。默认单位是秒也可以指定TimeUnitTest Timeout(2) void mustFinishWithinTwoSeconds() { // 逻辑必须2秒内返回 } Test Timeout(value 500, unit TimeUnit.MILLISECONDS) void shouldBeVeryFast() { // 逻辑必须500毫秒内返回 }JUnit 5在处理Timeout时会把带超时方法的测试放到单独的执行线程中运行超时后测试线程会被中断并标记为失败。所以它不是一个单纯的“在同一个线程里记录开始时间和结束时间”的朴素实现而是真正尝试去中断长期运行的操作这是我比较依赖它的原因之一。不过你也要知道如果测试代码里发起了不可中断的操作比如一个阻塞的IO调用不能及时响应中断那么即使超时线程也不一定能立刻退出测试框架只能尽力处理。在类级别加Timeout等于给类里所有测试方法设置默认超时这很适合整套测试用例都不允许耗时的项目。5.2 业务超时和应用测试超时是两回事这里特别想强调一个区分业务超时是指被测代码自己定义的“处理不能超过多少毫秒”的规则通常写在业务代码内部比如调用外部接口最多3秒测试超时是JUnit对“这段测试代码必须在多少时间内完成”的限制。很多教程把这俩混在一起导致新手在业务代码没有超时机制时试图靠给测试加Timeout来“验证”业务超时这是不对的。如果你要测试业务代码里的超时逻辑正确做法是设一个很短的业务超时时间用mock把外部调用挂起然后断言业务代码按预期抛超时异常。Timeout在这里只是防止测试自身出问题而不是替代业务代码实现超时。反过来如果你只是担心某个测试在CI上偶尔因为环境慢而超时那也不是加Timeout的理由先想想是不是测试本身做得太重、依赖太多。5.3 我踩过的超时相关坑第一次写Timeout时我犯过一个低级错误给一个需要等待异步任务2秒完成的测试加了1秒超时结果每次必挂。这倒还好毕竟失败是显性的。真正烦的是另一种情况本地跑得飞快CI上一旦负载高就偶发超时。这时候盲目调大超时时间不是好选择我建议先缩小测试范围排除外部网络请求、减少线程池竞争、避免测试之间共享资源。如果实在无法避免就把超时设置得宽松一点作为“防止死循环”的最后防线而不是常规性能约束。另一个容易踩的坑是Timeout在线程池模型下有时表现得更“硬”。项目里如果已经有自定义线程池或者使用了并行测试那Timeout的执行上下文会更复杂。一个测试超时后线程虽然被标记失败但那个线程上的任务可能还在继续运行最终可能导致资源泄漏或者后续测试受干扰。所以超时时间不能拍脑袋定要结合测试花在准备、执行、清理等各阶段的耗时来评估留出合理余量。6. 动态测试与测试组织展示前几节聊的都是“把测试写好”这一节聊的是“把测试组织得像人话”。JUnit 5在这块提供了两个很有价值的能力TestFactory动态生成测试用例以及DisplayName、Nested这类让测试报告更可读的展示手段。很多开发者觉得这些只是“锦上添花”但我在项目里发现它们对测试的可维护性影响很大。6.1 TestFactory让测试用例本身可以编程生成动态测试允许你在运行时计算出一批测试用例。一个TestFactory方法可以返回Stream、Collection、Iterable或Iterator里面的每个元素都代表一个动态测试。最简单的例子TestFactory StreamDynamicTest dynamicTestsForOrders() { ListOrder orders loadTestOrders(); return orders.stream() .map(order - DynamicTest.dynamicTest( 订单金额计算 order.getId(), () - assertEquals(expectedAmount(order), order.calculateAmount()) )); }这段代码的威力在于测试用例的数量和内容不是写死的而是根据运行时数据计算出来的。比如你从配置文件里读了一批测试数据或者从数据库里查出了一批历史订单这些都能直接转成动态测试。每个动态测试都有自己的名字和结果失败时能精准定位到是哪一份数据出了问题。但要注意动态测试的测试方法本身不会触发BeforeEach和AfterEach因为这些钩子绑定的是TestFactory方法所在的测试实例生命周期。所以动态测试里的数据准备、清理逻辑都要靠自己写在动态测试的lambda表达式中。这一点是动态测试和参数化测试一个比较本质的区别选型时一定要想清楚。6.2 DisplayName与Nested把测试报告变成需求文档我见过太多测试类叫OrderServiceTest里面的方法叫test1、test2、checkStatus。测试跑完只有红绿完全看不出业务含义。JUnit 5的DisplayName就是为了解决这个问题Test DisplayName(创建订单时如果库存不足应该抛出库存不足异常) void shouldThrowWhenStockNotEnough() { // ... }中文显示名虽然有点长但测试失败时CI报告里直接能看到业务意图不用再翻代码猜这个测试在干嘛。我在很多团队里立过一条规定核心业务测试必须写DisplayName并且用“什么条件下、做什么事、期望什么结果”的格式来写。如果字符串太长那就说明方法本身职责不单一拆。Nested则可以把测试类按业务场景分层。比如一个支付服务测试类外层放通用准备逻辑内层分别定义“余额支付”“银行卡支付”“优惠券叠加”三个嵌套类。每个嵌套类里再写各自的测试方法。这样做的好处是测试报告会变成一个树形结构和需求文档的目录结构几乎一一对应。查找相关测试、定位失败点都变得很快。配合DisplayName之后这份测试报告甚至可以直接拿去做业务评审的支撑材料。6.3 覆盖率和“测试叙事能力”的关系很多团队把覆盖率当成唯一指标要求行覆盖、分支覆盖达到多少百分比。但我的看法是覆盖率只是一个辅助数字真正重要的是测试是否把业务规则讲清楚。动态测试和后缀展示这些功能本质上都在帮助测试代码获得“叙事能力”。同样的80%行覆盖率可能是一个写满test1的类也可能是一个用DisplayName把异常分支都解释清楚的测试套件维护成本天差地别。实际项目里我也会把动态测试和条件执行组合起来使用外部数据源可用时动态生成大量数据驱动测试数据源不可用时就跳过。这样既保证了CI上的执行质量又让本地开发保持轻量。这种组合用起来后我对“测试用例必须静态存在”这件事的执念很快就放下了。写测试的本质不是写一堆固定方法而是把这个系统该有的行为边界定义清楚。7. 配置文件与构建接入的实用建议除了注解之外JUnit 5还支持通过配置文件调整全局行为。把这些配置放在src/test/resources/junit-platform.properties里就能覆盖很多注解做不到的“整体设置”。这一节我把项目里最常用的几项配置和自己接入构建工具的过程整理出来顺便聊聊哪些调整值得做、哪些容易踩坑。7.1 junit-platform.properties 里的高价值配置项配置项作用我的推荐值junit.jupiter.execution.timeout.default给所有测试设置默认超时时间视项目而定通常不给全局默认junit.jupiter.execution.parallel.enabled是否启用并行执行小项目不建议开junit.jupiter.execution.parallel.mode.default并行模式same_thread/concurrent默认same_threadjunit.jupiter.displayname.generator.default全局显示名生成策略可配自定义类但不建议junit.jupiter.testinstance.lifecycle.default全局测试实例生命周期默认per_method保持默认最容易被误解的是并行执行。JUnit 5从5.3开始支持并行但并行测试不是“只要配置打开就自动安全”。如果测试之间共享数据库、文件、端口并行跑起来马上就是成片失败。我碰过不只一次团队兴致勃勃打开并行结果测试调了一天还没调完。所以我的建议是先不要全局开并行等测试互相隔离做得足够好之后再用小规模并行验证最后再逐步放开。7.2 Maven和Gradle里的接入方式JUnit 5的测试运行需要构建工具里启用JUnit Platform。Maven项目通常在pom.xml里配置surefire插件plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-surefire-plugin/artifactId version3.2.5/version /plugin只要项目依赖里引入了junit-jupiter相关依赖新版surefire会自动识别并运行JUnit 5测试。Gradle项目则是在build.gradle里加上test { useJUnitPlatform() }这一步看起来简单但很多新项目跑不起来测试根源就是构建工具只识别到了JUnit 4的注解没有把JUnit Platform接进来。排查的时候先确认junit-jupiter依赖在testImplementation/compileOnly里再看构建脚本是否声明了useJUnitPlatform()。另外一个跟构建有关的点在CI上跑测试时建议让测试报告直接输出到统一的目录配合构建插件的测试报告可以按测试类、测试方法快速定位失败用例。JUnit 5默认会生成XML报告构建工具会读取它不需要额外写报告逻辑关键是不要随意改报告输出路径。7.3 IDE里的执行与调试技巧大多数主流IDE对JUnit 5的支持都很好。你在IDE里可以直接右键点击测试类或测试方法选择运行失败时能跳到具体的断言行。这里有几个我日常用得很顺手的小技巧。第一个是给测试分组。如果项目里测试很多编写测试的时候尽量用Tag给它们打上标签。比如Tag(slow)标记慢测试Tag(db)标记依赖数据库的测试然后在构建工具或IDE里只跑某个标签的测试会方便很多。第二个是调试动态测试。动态测试因为生成过程比较复杂IDE的调试体验没有普通Test方法那么直接。我的做法是先在TestFactory方法里打断点看数据流是否正常再在动态测试lambda表达式里打断点看具体断言参数。如果动态测试数量很多也可以先临时改成只生成其中一条数据确认逻辑没问题后再恢复全量。第三个是显示名和测试树。IDE的测试运行窗口通常会把DisplayName显示出来配合Nested嵌套类整个测试树会非常清晰。如果团队成员反馈“看不懂测试”先别急着怪他们看看是不是测试类里全是test1、test2这种名字该用DisplayName和Nested把业务语义补上。7.4 把功能变成习惯的几条个人原则写了几年测试后我逐渐沉淀出几条很朴素的习惯。第一每个测试类的名字都说明它测的是哪个业务模块每个测试方法名都说明它验证什么行为测试代码从来不是“只要能过就行”。第二公共准备和清理逻辑尽量用生命周期钩子收敛避免每个测试方法里都重复贴一大段setup代码。第三环境相关的测试一定要有明确的跳过条件并且把条件写入代码注释防止后来人完全看不懂为什么有的测试没跑。这些习惯说起来都很简单但真正把项目里的测试代码从“能跑”变成“好维护”靠的就是这些小事。JUnit 5提供了一堆功能如果只是当成语法点去背用的时候还是无从下手只有把它们放进真实项目里遇到对应的场景再拿出来用这些功能才会变成你自己的工具箱。8. 常见问题与排查技巧实录最后把我在实际项目里遇到过的、以及很多同事问过的问题汇总成一张排查表方便你对照处理。这些问题单独看都不难但组合在一起几乎覆盖了JUnit 5核心功能使用中80%左右的常见卡点。现象可能原因解决思路BeforeAll报错Method must be static默认PER_METHOD下要求static改成static或给测试类加TestInstance(PER_CLASS)RepeatedTest跑了若干次后失败想继续看后续默认中断当前测试从失败信息看已执行次数再按需调整重复次数或断言逻辑Timeout偶发失败本地却正常CI环境慢、资源竞争、共享状态先隔离测试再评估是否确实需要永久超时限制条件执行不生效测试还是被跑了注解写在错误的测试类/方法上或者matches正则没匹配上检查注解位置、系统属性名、正则表达式Nested嵌套类执行顺序不符合预期对BeforeEach/AfterEach顺序理解偏差记住Before从小到大After从大到小参数化测试报告里参数看不懂没有配置name属性完善ParameterizedTest的name把参数含义展示出来动态测试里发现BeforeEach没执行动态测试不走普通测试生命周期钩子在动态测试的lambda里自行准备和清理数据中文DisplayName显示成乱码构建或终端编码问题检查项目文件编码、构建工具编码、IDE控制台编码测试跑不起来提示找不到测试构建工具没启用JUnit Platform确认依赖和useJUnitPlatform配置这些坑里我对两个问题的印象最深。第一个是BeforeAll的static问题。当时有个同事把新写的测试类从JUnit 4迁移过来在BeforeAll上写了一大段初始化代码结果一直报错折腾了半天才发现是JUnit 5改规则了。我后来在团队里统一了两个习惯一是新代码默认用PER_CLASS模式共享昂贵依赖二是所有BeforeAll方法哪怕不加static也写static从源头减少这类困惑。第二个是Timeout和并行执行叠加时的表现。项目刚开并行测试时我一直以为并行只会让速度变快直到发现几个带Timeout的测试开始神秘失败。查下来才明白并行环境下线程调度更加不确定超时时间设置的“余量”必须比串行时更大一些。那次之后我立了一个规矩并行测试和超时配置不要在项目里同时“拍脑袋”上线必须小步验证。排查问题时的另外一个心得是JUnit的测试报告远比控制台输出重要。每次看到失败的测试先不要急着改代码先去看报告里失败的是哪个类、哪条用例、哪一步断言。报告里写的失败信息往往已经包含了实际值和期望值对比一下就能猜出问题方向。这也再次验证了一点测试代码写清楚了排查效率自然高。与其事后各种debug不如从一开始就把命名、分组、条件、超时这些“周边功能”用到位让每个测试用例都能在最合适的环境里被稳定地执行。