4、测试套件与执行顺序：@Suite、@Order、@TestMethodOrder 的使用，以及如何组织大型测试集。

说实话，很多团队写单元测试，写到后面就乱了。几百个测试类堆在一起，跑一遍要半小时，还经常因为执行顺序不对导致误报。我当年在一个金融项目里就吃过这个亏——测试用例多了以后，每次构建都提心吊胆。

今天我们就聊聊怎么用 JUnit 5 的测试套件和执行顺序注解，把大型测试集管得服服帖帖。

为什么需要测试套件？

你想想看，一个模块有几十个测试类，你总不能每次都手动指定跑哪些吧？测试套件就是用来解决这个问题的。它像一个「测试清单」，告诉框架：这次要跑哪些测试类，按什么顺序跑。

JUnit 5 提供了 @Suite 注解，配合 @SelectClasses 或 @SelectPackages，就能轻松组织测试集。

@Suite 的基本用法

先看一个最简单的例子。假设我们有三个测试类：UserServiceTest、OrderServiceTest、PaymentServiceTest。我想把它们打包成一个「业务层测试套件」。

import org.junit.platform.suite.api.Suite;
import org.junit.platform.suite.api.SelectClasses;

@Suite
@SelectClasses({
    UserServiceTest.class,
    OrderServiceTest.class,
    PaymentServiceTest.class
})
public class BusinessServiceSuite {
    // 这个类不需要写任何测试方法
    // 它就是一个「调度员」
}

跑这个套件的时候，JUnit 会依次执行三个测试类里的所有测试方法。嗯，这里要注意：@Suite 注解是 JUnit 5 平台提供的，不是 JUnit Jupiter 的。所以你需要引入 junit-platform-suite-api 依赖。

按包选择测试类

如果测试类太多，一个个列出来太麻烦。可以用 @SelectPackages 按包名批量选择。

@Suite
@SelectPackages("com.example.service")
public class ServiceLayerSuite {
    // 会扫描 com.example.service 包下所有测试类
}

不过要小心：@SelectPackages 默认会递归扫描子包。如果你只想扫当前包，可以加 @IncludeClassNamePatterns 过滤。

@Suite
@SelectPackages("com.example.service")
@IncludeClassNamePatterns(".*Test")
public class ServiceLayerSuite {
    // 只匹配以 Test 结尾的类
}

测试执行顺序：为什么需要它？

我记得有一次，团队里有人写了一个测试，依赖另一个测试的执行结果。结果 CI 上跑的时候顺序变了，测试全挂。这就是典型的「测试间耦合」问题。

JUnit 5 提供了三种级别的顺序控制：

• 类级别：控制测试类的执行顺序（@Suite 配合 @Order）
• 方法级别：控制单个测试类里方法的执行顺序（@TestMethodOrder）
• 全局级别：通过配置文件控制整个项目的顺序

@Order：控制套件中的类顺序

在 @Suite 里，你可以用 @Order 注解给每个测试类指定优先级。数字越小，越先执行。

@Suite
@SelectClasses({
    UserServiceTest.class,
    OrderServiceTest.class,
    PaymentServiceTest.class
})
public class BusinessServiceSuite {
    // 默认按类名排序，但我们可以显式指定
}

// 在每个测试类上加上 @Order
@Order(1)
class UserServiceTest {
    // 最先执行
}

@Order(2)
class OrderServiceTest {
    // 第二个执行
}

@Order(3)
class PaymentServiceTest {
    // 最后执行
}

@TestMethodOrder：控制方法执行顺序

有时候，一个测试类里有多个测试方法，你想按特定顺序执行。比如先跑「初始化」方法，再跑「业务逻辑」方法。

JUnit 5 提供了 @TestMethodOrder 注解，配合 MethodOrderer 实现。

import org.junit.jupiter.api.TestMethodOrder;
import org.junit.jupiter.api.MethodOrderer;
import org.junit.jupiter.api.Order;

@TestMethodOrder(MethodOrderer.OrderAnnotation.class)
class UserServiceTest {

    @Test
    @Order(1)
    void testInit() {
        // 先初始化
    }

    @Test
    @Order(2)
    void testCreateUser() {
        // 再创建用户
    }

    @Test
    @Order(3)
    void testDeleteUser() {
        // 最后删除
    }
}

除了 OrderAnnotation，还有几种内置的排序策略：

策略	说明	适用场景
MethodOrderer.OrderAnnotation	按 @Order 注解的值排序	需要精细控制顺序
MethodOrderer.DisplayName	按方法显示名称字母排序	按名称组织测试
MethodOrderer.MethodName	按方法名字母排序	简单排序需求
MethodOrderer.Random	随机顺序	检测测试间耦合

如何组织大型测试集？

项目大了以后，测试集的组织就成了一件头疼的事。我参与过一个微服务项目，有 2000 多个测试类。我们用了三层套件结构：

1. 单元测试套件：每个模块一个，只跑该模块的单元测试
2. 集成测试套件：跨模块的集成测试，按业务场景分组
3. 全量回归套件：包含所有测试，用于 CI 构建

举个例子：

// 第一层：模块级套件
@Suite
@SelectPackages("com.example.user")
public class UserModuleSuite {}

// 第二层：集成测试套件
@Suite
@SelectClasses({
    UserOrderIntegrationTest.class,
    PaymentFlowTest.class
})
public class IntegrationSuite {}

// 第三层：全量回归套件
@Suite
@SelectPackages({
    "com.example.user",
    "com.example.order",
    "com.example.payment"
})
public class FullRegressionSuite {}

这样分层的好处是：

• 开发阶段只跑模块级套件，速度快
• 提测前跑集成套件，验证交互逻辑
• 上线前跑全量回归，确保没有副作用

一些实战经验

最后分享几个我在项目中踩过的坑：

• 不要滥用 @Suite：套件是组织工具，不是性能优化工具。如果测试跑得慢，先优化测试本身，而不是用套件「跳过」某些测试。
• 注意套件之间的依赖：我曾经见过 A 套件依赖 B 套件的执行结果。这种设计非常脆弱，一旦顺序变了就全挂。
• 善用 @Nested：对于复杂的测试类，可以用 @Nested 内部类来分组，比拆成多个测试类更清晰。
• CI 中建议用随机顺序：在持续集成环境里，偶尔用 MethodOrderer.Random 跑一遍，能帮你发现隐藏的测试依赖问题。