JUnit 默认不保证测试方法执行顺序以确保独立性；需控制顺序时，JUnit 4 用 @FixMethodOrder（推荐 NAME_ASCENDING），JUnit 5 用 @TestMethodOrder + @Order；生命周期注解不影响测试方法顺序；应优先重构消除隐式依赖。
JUnit 默认不保证测试方法的执行顺序，这是为了强调单元测试应彼此独立。但当确实需要控制顺序（比如集成场景、状态依赖或调试），可以通过注解实现规范化的执行顺序——关键在于选择合适的方式，并配合命名或结构约束。
使用 @FixMethodOrder 指定类级排序规则
这是 JUnit 4.11+ 提供的官方方式，需在测试类上添加该注解，有三种可选策略：
-
MethodSorters.NAME_ASCENDING：按方法名字典序升序执行（最推荐）。要求测试方法命名有规律，例如
test001_init()、test002_save()、test003_verify()，确保顺序稳定且跨平台一致。 -
MethodSorters.DEFAULT：基于方法名的
hashCode()排序，结果在单次运行中确定，但不同系统或 JDK 版本下可能不同，不建议用于生产级顺序依赖。 - MethodSorters.JVM：完全交由 JVM 返回的方法列表顺序，不可预测，仅适合临时调试，不应在 CI 或自动化流程中使用。
JUnit 5 中用 @TestMethodOrder + @Order 实现更灵活控制
JUnit 5 引入了更清晰的语义化方式：
- 在测试类上加
@TestMethodOrder(MethodOrderer.OrderAnnotation.class)； - 每个
@Test方法上标注@Order(n)，n 为整数（如@Order(1)、@Order(2)）； - 支持负数和大整数，便于后续插入新步骤（如在
@Order(1)和@Order(2)之间加@Order(15)）。
这种方式比命名排序更直观、不易出错，也无需修改方法名，适合逻辑性强的多步测试流。
立即学习“Java免费学习笔记（深入）”；
deep-java-review
下载
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
注意生命周期注解的执行时机不等于测试方法顺序
像 @BeforeEach、@AfterEach、@BeforeAll、@AfterAll 这些注解控制的是“准备/清理”阶段，它们的执行是固定的：
-
@BeforeAll→ 所有测试方法前执行一次（静态方法）； -
@BeforeEach→ 每个测试方法前执行； -
@Test方法按你指定的顺序执行； -
@AfterEach→ 每个测试方法后执行； -
@AfterAll→ 所有测试方法后执行一次（静态方法）。
它们构成完整生命周期，但不会改变 @Test 方法之间的相对顺序——顺序仍由 @FixMethodOrder 或 @TestMethodOrder 决定。
避免隐式依赖，优先重构测试设计
强制顺序虽可行，但违背单元测试“独立可重跑”的原则。如果多个测试必须串行执行，往往说明：
- 测试间共享了外部状态（如数据库、文件、静态变量）；
- 应改用内存数据库、Mock 对象或每次测试自建/清理资源；
- 复杂流程更适合写成一个测试方法内分段断言，而非拆成多个带顺序依赖的
@Test。
真正需要顺序的场景，建议先评估是否可通过测试结构优化消除依赖，再考虑注解控制。
