junit默认的`per_method`测试实例生命周期导致每个测试方法执行时都会创建新的测试类实例，从而使`final`字段等在方法间重载。本文将深入解析这一行为，并介绍如何通过`@testinstance(testinstance.lifecycle.per_class)`注解将其修改为`per_class`，以在所有测试方法间共享同一实例，同时探讨其对测试隔离性的影响。
1. 理解JUnit测试实例的默认行为
在JUnit 5（及更高版本）中，测试类实例的默认生命周期策略是TestInstance.Lifecycle.PER_METHOD。这意味着对于测试类中的每一个@Test注解的方法，JUnit都会创建一个全新的测试类实例来执行该方法。这种设计旨在确保测试方法间的最大程度隔离性，避免一个测试方法的执行状态影响到其他测试方法。
当一个测试类被实例化时，其成员变量（包括final字段）会在构造函数执行前被初始化。如果这些字段在声明时就被赋予了通过某种随机或动态方式生成的值，那么每次创建新实例时，这些字段都会获得新的值。
例如，考虑以下测试类：
import org.junit.jupiter.api.Test;
import java.util.UUID;
class DefaultLifecycleExampleTest {
// final字段在每次类实例化时都会被初始化
private final String uniqueId = UUID.randomUUID().toString();
@Test
void testMethodA() {
System.out.println("Test Method A - Unique ID: " + uniqueId);
// 第一次运行时会打印一个UUID
}
@Test
void testMethodB() {
System.out.println("Test Method B - Unique ID: " + uniqueId);
// 第二次运行时，由于是新的实例，会打印一个不同的UUID
}
}运行上述测试时，你会观察到testMethodA和testMethodB打印出的uniqueId是不同的。这是因为JUnit为每个测试方法分别创建了DefaultLifecycleExampleTest的一个新实例。这种行为是JUnit为了保证测试隔离性而设计的，是其核心原则之一。测试实例的hashCode发生变化，也直接证明了这是不同的对象实例。
2. 改变测试实例生命周期：PER_CLASS
在某些特定场景下，我们可能希望所有的测试方法共享同一个测试类实例，例如为了优化资源（如重量级对象或数据库连接的初始化）或在方法间共享不可变状态。JUnit提供了@TestInstance注解来改变测试实例的生命周期策略。
通过将@TestInstance(TestInstance.Lifecycle.PER_CLASS)注解应用于测试类，可以指示JUnit为整个测试类只创建一个实例，所有@Test方法都将在这个共享实例上执行。
import org.junit.jupiter.api.Test;
import org.junit.jupiter.api.TestInstance;
import java.util.UUID;
@TestInstance(TestInstance.Lifecycle.PER_CLASS)
class PerClassLifecycleExampleTest {
// final字段只在类第一次实例化时被初始化一次
private final String uniqueId = UUID.randomUUID().toString();
@Test
void testMethodC() {
System.out.println("Test Method C - Unique ID: " + uniqueId);
// 第一次运行时会打印一个UUID
}
@Test
void testMethodD() {
System.out.println("Test Method D - Unique ID: " + uniqueId);
// 第二次运行时，由于是共享实例，会打印与testMethodC相同的UUID
}
}运行PerClassLifecycleExampleTest时，testMethodC和testMethodD将打印出相同的uniqueId，这表明它们共享了同一个PerClassLifecycleExampleTest实例。
注意事项：
- 当使用PER_CLASS生命周期时，@BeforeAll和@AfterAll方法不再需要声明为static。它们可以直接作为实例方法使用，因为此时存在一个共享的类实例。
3. PER_CLASS生命周期的考量与注意事项
虽然PER_CLASS生命周期提供了灵活性，但它改变了JUnit默认的测试隔离模型，因此在使用时需要仔细权衡其优缺点。
3.1 优点
- 资源优化： 对于那些初始化成本高昂的资源（如数据库连接池、复杂的Spring上下文、重量级服务客户端等），PER_CLASS可以显著减少初始化次数，从而加快测试套件的执行速度。
- 状态共享： 允许在多个测试方法之间共享不可变的状态或预计算的结果，避免重复设置。
- 非静态的@BeforeAll/@AfterAll： 在PER_CLASS模式下，@BeforeAll和@AfterAll方法可以是非静态的，这使得它们可以访问测试类的实例变量，从而在设置和清理阶段进行更灵活的操作。
3.2 缺点与风险
- 违反测试隔离性： PER_CLASS最主要的风险是可能违反单元测试的“独立性（Independent）”原则（FIRST原则之一）。如果测试类实例包含可变状态，并且在某个测试方法中被修改，那么这些修改可能会影响到后续测试方法的执行，导致测试结果不稳定、相互依赖或难以预测。
- 状态泄露： 状态泄露是测试不稳定的常见原因。一个测试的副作用（side effect）可能会“污染”共享实例的状态，从而导致其他测试失败，即使这些测试本身的代码是正确的。
- 调试复杂性增加： 当测试失败时，由于存在状态共享和潜在的相互影响，定位问题的根源可能会变得更加复杂。
3.3 最佳实践
- 谨慎使用： 仅在确实需要共享状态或优化资源且能够严格控制状态管理时才使用PER_CLASS。
- 确保状态不可变或重置： 如果测试类实例包含共享状态，请确保该状态是不可变的。如果必须共享可变状态，务必在每个测试方法执行之前（通过@BeforeEach）或之后（通过@AfterEach）将其重置到已知状态，以保证测试的独立性。
- 优先保持独立性： 单元测试的核心价值在于其快速、可靠和独立性。在大多数情况下，应优先保持PER_METHOD的默认生命周期，以确保测试的健壮性。
- 集成测试场景： PER_CLASS在集成测试或端到端测试场景中可能更为常见，因为这些测试通常涉及更复杂的环境设置和资源消耗，并且对严格的单元隔离性要求相对宽松。
4. 总结
JUnit默认的PER_METHOD测试实例生命周期是其设计哲学的一部分，旨在通过为每个测试方法提供独立的实例来确保测试的隔离性和可靠性。当您观察到final字段在不同测试方法间变化时，这正是这种默认行为的体现。
通过使用@TestInstance(TestInstance.Lifecycle.PER_CLASS)注解，您可以改变这一行为，使所有测试方法共享同一个测试类实例。这在某些特定场景下可以带来性能优势和便利性，但同时也引入了状态泄露和测试方法间相互依赖的风险。因此，在使用PER_CLASS时，务必充分理解其影响，并采取适当的措施（如确保状态不可变或每次重置）来维护测试的健壮性。在绝大多数单元测试场景中，建议坚持使用默认的PER_METHOD生命周期，以最大化测试的独立性和可维护性。
