TestInstance lifecycle per class in JUnit - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ Predict Output

intermediate

JUnit TestInstance Lifecycle: Output of Counter Increment

Consider the following JUnit 5 test class using @TestInstance(Lifecycle.PER_CLASS). What will be the output when all tests run?

JUnit

import org.junit.jupiter.api.*;

@TestInstance(TestInstance.Lifecycle.PER_CLASS)
public class CounterTest {
    private int counter = 0;

    @Test
    void testOne() {
        counter++;
        System.out.println("Counter in testOne: " + counter);
    }

    @Test
    void testTwo() {
        counter++;
        System.out.println("Counter in testTwo: " + counter);
    }

    @Test
    void testThree() {
        counter++;
        System.out.println("Counter in testThree: " + counter);
    }
}

A Counter in testOne: 1\nCounter in testTwo: 2\nCounter in testThree: 3

B Counter in testOne: 1\nCounter in testTwo: 1\nCounter in testThree: 1

C Counter in testOne: 0\nCounter in testTwo: 1\nCounter in testThree: 2

D Counter in testOne: 3\nCounter in testTwo: 3\nCounter in testThree: 3

💡 Hint

Remember that with PER_CLASS lifecycle, the same test instance is used for all tests.

With @TestInstance(Lifecycle.PER_CLASS), JUnit creates one instance of the test class and reuses it for all test methods. The counter variable is incremented cumulatively across tests, so the output shows increasing values.

❓ assertion

intermediate

Correct Assertion for PER_CLASS Lifecycle Shared State

Given a JUnit 5 test class with @TestInstance(Lifecycle.PER_CLASS) and a shared list that tests add elements, which assertion correctly verifies the list size after two tests have run?

JUnit

import org.junit.jupiter.api.*;
import java.util.*;

@TestInstance(TestInstance.Lifecycle.PER_CLASS)
public class ListTest {
    private List<String> items = new ArrayList<>();

    @Test
    void addFirst() {
        items.add("first");
    }

    @Test
    void addSecond() {
        items.add("second");
    }

    @Test
    void verifySize() {
        // Which assertion below correctly checks the list size?
    }
}

A Assertions.assertEquals(2, items.size());

B Assertions.assertEquals(1, items.size());

C Assertions.assertTrue(items.isEmpty());

D Assertions.assertNull(items);

💡 Hint

With PER_CLASS lifecycle, the list is shared and accumulates elements added in previous tests.

Since the same instance is used for all tests, the list keeps elements added in previous tests. After addFirst and addSecond run, the list size is 2.

🔧 Debug

advanced

Debugging Unexpected Test Behavior with PER_CLASS Lifecycle

A developer notices that tests in a JUnit 5 class annotated with @TestInstance(Lifecycle.PER_CLASS) fail intermittently due to shared mutable state. What is the most likely cause?

A Static fields are reset before each test, causing loss of data.

B JUnit creates a new instance per test, so fields are always reset causing inconsistent state.

C The @TestInstance annotation is ignored, so tests run in parallel causing race conditions.

D Tests share the same instance, so mutable fields retain changes between tests causing interference.

💡 Hint

Think about how PER_CLASS lifecycle affects instance variables.

With PER_CLASS lifecycle, the same test instance is reused, so mutable fields keep their values across tests. If tests modify these fields without resetting, it causes flaky failures.

🧠 Conceptual

advanced

Effect of PER_CLASS Lifecycle on @BeforeEach and @AfterEach

In a JUnit 5 test class annotated with @TestInstance(Lifecycle.PER_CLASS), how often are methods annotated with @BeforeEach and @AfterEach executed?

A @BeforeEach and @AfterEach run only once for the entire test class.

B @BeforeEach and @AfterEach run once per test method invocation, using the same test instance.

C @BeforeEach and @AfterEach run once per test instance creation, which is once per test method.

D @BeforeEach and @AfterEach do not run when using PER_CLASS lifecycle.

💡 Hint

Consider the difference between test instance lifecycle and lifecycle of setup/teardown methods.

Even with PER_CLASS lifecycle, @BeforeEach and @AfterEach run before and after each test method, but the same test instance is reused.

❓ framework

expert

Choosing TestInstance Lifecycle for Stateful Integration Tests

You are designing integration tests that require expensive setup and teardown, and tests must share state between methods. Which JUnit 5 TestInstance lifecycle is best and why?

A PER_CLASS, because it runs each test in a separate thread for parallel execution.

B PER_METHOD, because it creates a new instance per test, ensuring complete isolation and no shared state.

C PER_CLASS, because it creates one instance for all tests, allowing shared state and reducing setup overhead.

D PER_METHOD, because it caches expensive setup between tests automatically.

💡 Hint

Think about instance reuse and shared state benefits.

PER_CLASS lifecycle creates one test instance for all tests, so state can be shared and setup/teardown can be done once, improving performance for expensive operations.