RepeatedTest with @TestInstance(PER_CLASS) yields varying instance IDs

Does a @RepeatedTest reuse the same test instance when the class is annotated with @TestInstance(PER_CLASS)?

In a standard JUnit 5 test run, the @TestInstance(Lifecycle.PER_CLASS) annotation tells the engine to create a single instance of the test class and reuse it for all test methods, including repetitions. In practice, the same object is invoked for every repetition, so System.identityHashCode(this) will stay constant across all @RepeatedTest executions.

Confirmed facts

• JUnit 5’s default lifecycle (PER_METHOD) creates a new instance for each test method and each repetition.
• When PER_CLASS is declared, the engine normally keeps the same instance for the whole test class.
• Older JUnit Platform releases (≤ 1.7) contained a bug that caused @RepeatedTest to bypass the PER_CLASS lifecycle, resulting in a fresh instance per repetition.
• Recent releases (1.8+), including the current 5.10.x series, have corrected this behavior; the same instance is reused unless overridden by custom extensions or special class structures.

Common causes of varying instance IDs

• Non‑default constructor – JUnit will invoke the constructor for each repetition if it cannot reuse the existing instance.
• Custom Extension – Extensions that implement TestInstancePostProcessor or use @ExtendWith may force a new instance per invocation.
• Nested or Parameterized tests – These have independent lifecycles unless explicitly marked with @TestInstance(PER_CLASS) inside the nested class.
• Running on an older JUnit Platform that still has the bug.

Steps to verify the behavior in your environment

1. Add a static counter and log System.identityHashCode(this) inside the @RepeatedTest method.

   @RepeatedTest(5)
   void testRepeat() {
       System.out.println("Instance hash: " + System.identityHashCode(this));
   }

2. Run the test normally and observe whether the printed hash stays the same across all five repetitions.
3. If the hash changes, check the following:
   • Is the test class declared with a non‑default constructor? Replace it with a no‑arg constructor and rerun.
   • Does the class use a custom @ExtendWith extension that might override the lifecycle? Temporarily remove the extension.
   • What JUnit Platform version is in the classpath? Run mvn -q -Dexec.executable=echo -Dexec.args='%{project.version}' --non-recursive exec:exec or inspect the IDE’s dependency tree.
4. If the hash remains constant, the engine is reusing the instance as expected. If not, you’re likely on a platform version that still triggers the bug or have an interfering extension.

What to do if you need stable reuse

• Pin the JUnit Platform to a recent stable release (≥ 1.8) in your build configuration.
• Ensure the test class has a public no‑arg constructor.
• Avoid or adjust custom extensions that manipulate the test instance.
• For nested tests, annotate the nested class with @TestInstance(PER_CLASS) as well.

Missing diagnostic detail

To provide a definitive recommendation, could you share the exact JUnit 5 and JUnit Platform versions you are using? This will confirm whether the current release guarantees instance reuse across repetitions.