本文深入探讨junit测试中观察到的类重载现象，解释其根本原因在于junit默认的`per_method`测试实例生命周期。我们将阐述此行为导致每个测试方法获得独立类实例的机制，并介绍如何通过`@testinstance(testinstance.lifecycle.per_class)`注解将其修改为`per_class`模式，从而在所有测试方法间共享同一实例。同时，文章还将强调使用`per_class`时需注意的测试隔离原则，以确保测试的可靠性和独立性。
在进行JUnit单元测试时，开发者有时会观察到一种现象：即使测试类中存在final修饰的字段，在不同的测试方法执行时，这些字段的值也会发生变化，甚至测试类的哈希码（hashcode）也可能改变。这表明在每个测试方法执行前，测试类实例被重新创建了。
观察到的现象
考虑以下JUnit测试类示例：
import org.apache.commons.lang3.RandomStringUtils; // 假设已引入此依赖
import org.junit.jupiter.api.Test;
class SomeTest {
private final String aRandomString = RandomStringUtils.randomAlphabetic(10);
@Test
void a() {
System.out.println("Test a: " + aRandomString + ", Hash: " + this.hashCode());
}
@Test
void b() {
System.out.println("Test b: " + aRandomString + ", Hash: " + this.hashCode());
}
}当运行SomeTest中的a()和b()方法时，我们会发现aRandomString的值在两个方法中是不同的，并且this.hashCode()也会显示不同的值。这明确指出，a()和b()方法是在不同的SomeTest实例上执行的。
根本原因：JUnit测试实例生命周期
这种行为的根本原因在于JUnit 5（JUnit Jupiter）默认的测试实例生命周期策略。JUnit提供了两种主要的测试实例生命周期模式：
TestInstance.Lifecycle.PER_METHOD (默认模式)： 在这种模式下，JUnit会在执行每个测试方法之前，为测试类创建一个全新的实例。这意味着每个@Test方法都将在一个独立的、全新的测试类实例上运行。所有非静态的成员变量（包括final字段）都会在每次创建实例时重新初始化。这种模式确保了测试方法之间的完全隔离，一个测试方法的执行不会影响到另一个测试方法的状态，这符合单元测试的"FIRST"原则（Fast, Independent, Repeatable, Self-validating, Timely）。
TestInstance.Lifecycle.PER_CLASS： 在这种模式下，JUnit只会在执行所有测试方法之前，为测试类创建一个实例。所有的@Test方法都将共享这同一个测试类实例。这意味着成员变量（包括final字段）只会在实例创建时初始化一次，并在所有测试方法之间保持其状态。
解决方案：调整实例生命周期
要改变默认的PER_METHOD行为，使其在所有测试方法之间共享同一个测试类实例，可以使用@TestInstance注解，并将其Lifecycle参数设置为PER_CLASS。
import org.apache.commons.lang3.RandomStringUtils;
import org.junit.jupiter.api.Test;
import org.junit.jupiter.api.TestInstance;
@TestInstance(TestInstance.Lifecycle.PER_CLASS)
class SomeTestWithPerClass {
private final String aRandomString = RandomStringUtils.randomAlphabetic(10);
@Test
void a() {
System.out.println("Test a: " + aRandomString + ", Hash: " + this.hashCode());
}
@Test
void b() {
System.out.println("Test b: " + aRandomString + ", Hash: " + this.hashCode());
}
}在上述代码中，当运行a()和b()方法时，你会发现aRandomString的值在两个方法中是相同的，并且this.hashCode()也会显示相同的值。这表明两个测试方法共享了同一个SomeTestWithPerClass实例。
使用PER_CLASS的注意事项与最佳实践
尽管PER_CLASS模式可以解决类重载的问题，但使用时需要非常谨慎，因为它可能违反单元测试的"FIRST"原则，特别是"Independent"（独立性）原则。
- 测试隔离性问题：当多个测试方法共享同一个实例时，一个测试方法对实例状态的修改可能会影响后续测试方法的执行结果。这会导致测试变得脆弱，难以理解和维护，并可能引入难以调试的副作用。
- 状态管理复杂性：如果测试类中存在可变状态，那么在PER_CLASS模式下，你需要在每个测试方法执行前后手动清理或重置这些状态，以确保测试的独立性。这通常需要结合@BeforeEach和@AfterEach注解来实现，但增加了测试的复杂性。
-
适用场景：
- 性能优化：当测试类的初始化（例如，数据库连接、Spring上下文加载等）成本非常高昂，且这种初始化在所有测试方法中都是通用的，那么使用PER_CLASS可以显著减少测试运行时间。这在集成测试或端到端测试中更为常见。
- @BeforeAll和@AfterAll的使用：在PER_CLASS模式下，@BeforeAll和@AfterAll方法可以是非静态的。这在某些情况下提供了便利，例如，当需要在测试实例中访问成员变量来执行全局设置或清理时。
- 测试生命周期回调：当需要在整个测试类生命周期中维护一个单一资源时，PER_CLASS模式结合@BeforeAll和@AfterAll可以更好地管理资源。
推荐做法：
- 默认坚持PER_METHOD：对于大多数单元测试，保持JUnit默认的PER_METHOD生命周期是最佳实践。它强制测试方法独立，更容易编写、理解和维护。
- 谨慎使用PER_CLASS：仅当有明确的性能优化需求，且能够妥善处理测试状态管理和隔离问题时，才考虑使用PER_CLASS。在使用时，务必确保测试方法之间没有隐式依赖，并且任何共享的可变状态都得到了正确的重置或清理。
- 优先考虑依赖注入和模拟：如果测试需要复杂的设置，可以考虑使用依赖注入框架（如Spring）来管理依赖，并通过模拟（Mocking）技术隔离外部依赖，而不是依赖于PER_CLASS来共享状态。
总结
JUnit测试中观察到的类重载现象是其默认PER_METHOD测试实例生命周期策略的体现，旨在确保测试方法间的隔离性。虽然可以通过@TestInstance(TestInstance.Lifecycle.PER_CLASS)注解改变这一行为，但在采用PER_CLASS模式时，必须充分理解其对测试隔离性可能产生的影响，并采取适当的措施来维护测试的独立性和可靠性。对于大多数单元测试而言，遵循默认的PER_METHOD策略仍是最佳实践。
