本文深入探讨junit测试中类实例及其字段在不同测试方法间重载的现象。默认的`per_method`生命周期导致每个测试方法都使用独立的测试类实例，从而使实例级字段（包括`final`字段）在方法间表现出不同的值。文章详细解释了这一机制，并提供了通过`@testinstance(testinstance.lifecycle.per_class)`改变生命周期的解决方案，同时强调其潜在的副作用及最佳实践，以帮助开发者更好地管理测试状态。
在进行JUnit单元测试时，开发者有时会观察到一种现象：即使是声明为final的实例字段，在同一个测试类中的不同@Test方法执行时，其值也可能发生变化，或者测试类实例本身的哈希码在不同方法间不同。这通常会让人感到困惑，尤其是在期望final字段保持不变的情况下。这种行为并非偶然，而是JUnit测试框架默认生命周期管理机制的体现。
JUnit测试实例生命周期机制
要理解上述现象，核心在于掌握JUnit（特别是JUnit 5）如何管理测试类的实例。JUnit提供了两种主要的测试实例生命周期模式：PER_METHOD（默认）和PER_CLASS。
默认行为：PER_METHOD
JUnit 5的默认测试实例生命周期是TestInstance.Lifecycle.PER_METHOD。这意味着对于测试类中的每一个@Test方法，JUnit都会创建一个全新的、独立的测试类实例。
当一个测试类被实例化时，其所有的实例变量（包括final修饰的字段）都会被初始化。如果这些字段的初始化涉及随机值生成或外部依赖，那么每次创建新实例时，它们都会被重新初始化，从而可能获得不同的值。这就是为什么在以下示例中，aRandomString字段在a()和b()方法中会表现出不同的哈希码或实际值：
import org.junit.jupiter.api.Test;
import org.apache.commons.lang3.RandomStringUtils; // 假设已引入Apache Commons Lang库
class SomeTest {
// 实例字段，在每次创建SomeTest实例时都会被初始化
private final String aRandomString = RandomStringUtils.randomAlphabetic(10);
@Test
void a() {
// 在方法a执行时，会有一个SomeTest实例，其aRandomString被初始化
System.out.println("Method a: " + aRandomString + " (HashCode: " + aRandomString.hashCode() + ")");
}
@Test
void b() {
// 在方法b执行时，会创建另一个SomeTest实例，其aRandomString再次被初始化
System.out.println("Method b: " + aRandomString + " (HashCode: " + aRandomString.hashCode() + ")");
}
}运行上述代码，你会发现aRandomString的值和哈希码在a()和b()方法中通常是不同的。这种PER_METHOD模式的设计初衷是为了确保测试之间的完全隔离，每个测试方法都在一个“干净”的环境中运行，避免了测试之间的状态污染，这符合单元测试的“独立性”原则。
改变生命周期：PER_CLASS模式
如果确实需要让所有测试方法共享同一个测试类实例，从而保持实例字段在所有测试方法中的一致性，可以通过使用@TestInstance注解来改变生命周期模式。
解决方案：@TestInstance注解
通过在测试类上添加@TestInstance(TestInstance.Lifecycle.PER_CLASS)注解，可以指示JUnit为整个测试类只创建一个实例。这意味着该测试类的所有@Test方法都将在这个单一实例上执行。
在这种PER_CLASS模式下，测试类的实例变量（包括final字段）只会在测试类首次加载并实例化时初始化一次，之后在所有测试方法中都将保持相同的值。
import org.junit.jupiter.api.Test;
import org.junit.jupiter.api.TestInstance;
import org.apache.commons.lang3.RandomStringUtils; // 假设已引入Apache Commons Lang库
@TestInstance(TestInstance.Lifecycle.PER_CLASS) // 声明为PER_CLASS生命周期
class SomeTestWithPerClass {
// 实例字段，只在测试类首次实例化时初始化一次
private final String aRandomString = RandomStringUtils.randomAlphabetic(10);
@Test
void a() {
// 在方法a执行时，使用共享的SomeTestWithPerClass实例
System.out.println("Method a: " + aRandomString + " (HashCode: " + aRandomString.hashCode() + ")");
}
@Test
void b() {
// 在方法b执行时，仍然使用相同的共享实例
System.out.println("Method b: " + aRandomString + " (HashCode: " + aRandomString.hashCode() + ")");
}
}运行带有@TestInstance(TestInstance.Lifecycle.PER_CLASS)的上述代码，你会发现aRandomString的值和哈希码在a()和b()方法中将是相同的。
注意事项与最佳实践
虽然PER_CLASS模式可以解决实例字段在测试方法间重初始化的“问题”，但使用它必须非常谨慎，因为它可能会引入新的问题，并违反单元测试的一些核心原则。
测试隔离原则
单元测试的一个黄金原则是“独立性”：每个测试都应该独立于其他测试，其结果不应受到其他测试的执行顺序或副作用的影响。PER_METHOD模式正是为了强制这种隔离而设计的。它确保每个测试方法都从一个干净、初始化的状态开始。
PER_CLASS的潜在风险
使用PER_CLASS引入了共享状态。如果测试方法修改了实例变量（即使不是final字段），这些修改可能会影响后续执行的测试方法。这可能导致：
- 测试泄漏： 一个测试的副作用影响了另一个测试。
- 测试顺序依赖： 测试只有在特定顺序下才能通过，这使得测试变得脆弱和难以维护。
- 测试结果不稳定： 相同的代码，在不同执行环境下可能产生不同结果。
这些问题会严重损害测试的可靠性、可重复性和可维护性，使得调试变得异常困难。因此，除非有非常明确且充分的理由，否则应尽量避免使用PER_CLASS。
何时考虑使用PER_CLASS
在少数特定场景下，PER_CLASS模式可能是有益的：
-
昂贵的一次性设置： 当测试类需要进行一次性、耗时且不影响测试隔离的设置时，例如：
- 启动一个嵌入式数据库。
- 加载大量只读的测试数据。
- 初始化一个复杂的外部服务客户端。 在这种情况下，可以配合@BeforeAll和@AfterAll注解来管理这些资源的生命周期，确保它们只在所有测试开始前设置一次，并在所有测试结束后清理。
- 特殊测试类型： 在某些集成测试或端到端测试中，可能需要模拟更真实的共享状态环境，但即便如此，也应优先考虑其他管理共享状态的方法，例如使用Spring的测试上下文缓存。
- 性能优化： 在极端情况下，如果测试类的实例化成本极高，且能够严格保证测试之间无状态污染，PER_CLASS可以带来性能提升。但通常情况下，测试的可靠性远比微小的性能提升更重要。
总结
JUnit默认的PER_METHOD生命周期是导致测试类实例及其实例字段在不同测试方法间重初始化的根本原因。这种设计旨在确保测试的隔离性和独立性，是单元测试的最佳实践。通过@TestInstance(TestInstance.Lifecycle.PER_CLASS)注解，可以改变这一行为，使得所有测试方法共享同一个测试类实例。然而，采用PER_CLASS模式必须慎重，因为它可能引入共享状态问题，破坏测试的独立性，增加测试的脆弱性。在决定使用PER_CLASS之前，务必权衡性能优化与测试可靠性之间的利弊，并确保能够有效地管理共享状态，以避免引入难以调试的测试缺陷。
