Why lifecycle hooks manage setup and teardown in JUnit - Challenge Your Understanding

Challenge - 5 Problems

🧠 Conceptual

intermediate

Purpose of @BeforeEach in JUnit

In JUnit testing, what is the main purpose of the @BeforeEach lifecycle hook?

A To run code once before all tests in the class

B To run code before each individual test method

C To run code after each test method

D To clean up resources after all tests finish

💡 Hint

Think about preparing the environment fresh for every test.

The @BeforeEach hook runs before every test method to set up a clean state. This ensures tests do not affect each other.

🧠 Conceptual

intermediate

Role of @AfterAll in JUnit

What is the role of the @AfterAll lifecycle hook in JUnit testing?

A To initialize resources before any tests run

B To run cleanup code after each test method

C To run code before each test method

D To run cleanup code once after all tests in the class have run

💡 Hint

Think about releasing shared resources after all tests finish.

@AfterAll runs once after all tests complete, ideal for releasing shared resources like database connections.

❓ Predict Output

advanced

Output of JUnit lifecycle hooks order

Given the following JUnit test class, what is the order of printed output when running all tests?

JUnit

import org.junit.jupiter.api.*;

@TestInstance(TestInstance.Lifecycle.PER_CLASS)
public class SampleTest {

    @BeforeAll
    void beforeAll() {
        System.out.println("BeforeAll");
    }

    @BeforeEach
    void beforeEach() {
        System.out.println("BeforeEach");
    }

    @Test
    void testOne() {
        System.out.println("TestOne");
    }

    @Test
    void testTwo() {
        System.out.println("TestTwo");
    }

    @AfterEach
    void afterEach() {
        System.out.println("AfterEach");
    }

    @AfterAll
    void afterAll() {
        System.out.println("AfterAll");
    }
}

A BeforeAll, BeforeEach, TestOne, AfterEach, BeforeEach, TestTwo, AfterEach, AfterAll

B BeforeEach, BeforeAll, TestOne, AfterEach, BeforeEach, TestTwo, AfterEach, AfterAll

C BeforeAll, TestOne, BeforeEach, AfterEach, TestTwo, BeforeEach, AfterEach, AfterAll

D BeforeAll, BeforeEach, TestOne, BeforeEach, TestTwo, AfterEach, AfterEach, AfterAll

💡 Hint

Remember the order: BeforeAll once, BeforeEach before each test, AfterEach after each test, AfterAll once.

The lifecycle hooks run in this order: BeforeAll once, then for each test BeforeEach, test, AfterEach, and finally AfterAll once.

❓ assertion

advanced

Correct assertion for resource cleanup in @AfterEach

Which assertion correctly verifies that a resource is closed after each test using @AfterEach in JUnit?

JUnit

private Resource resource;

@BeforeEach
void setup() {
    resource = new Resource();
}

@AfterEach
void cleanup() {
    resource.close();
}

A assertEquals(null, resource);

B assertNull(resource);

C assertTrue(resource.isClosed());

D assertFalse(resource.isClosed());

💡 Hint

Check if the resource reports it is closed after cleanup.

After cleanup, the resource should be closed, so assertTrue(resource.isClosed()) is correct.

🔧 Debug

expert

Identify the problem with lifecycle hooks causing test interference

Consider this JUnit test class where tests sometimes fail due to shared state. What is the main issue causing this?

JUnit

import static org.junit.jupiter.api.Assertions.*;

public class SharedStateTest {
    private static int counter = 0;

    @BeforeAll
    static void init() {
        counter = 0;
    }

    @Test
    void testIncrement() {
        counter++;
        assertTrue(counter > 0);
    }

    @Test
    void testReset() {
        counter = 0;
        assertEquals(0, counter);
    }
}

A Using static variable counter causes shared state between tests leading to interference

B Lifecycle hooks are not annotated with @BeforeEach causing setup failure

C Incorrect assertion in testIncrement causes failure

D Missing @AfterEach to reset counter after each test

💡 Hint

Think about how static variables behave across tests.

Static variables keep their value across tests, causing shared state and test interference. Each test should have isolated state.