@AfterEach method in JUnit - Build an Automation Script

Verify resource cleanup after each test using @AfterEach

Preconditions (2)

Step 1: Create a test class with two test methods that open a resource (e.g., a list)

Step 2: In each test method, add an item to the resource

Step 3: Add an @AfterEach method that clears the resource after each test

Step 4: Run the tests

✅ Expected Result: After each test method runs, the resource is cleared so that the next test starts with an empty resource

Automation Requirements - JUnit 5

Assertions Needed:

Verify the resource is empty at the start of each test

Verify the resource contains the expected item after adding

Verify the resource is cleared after each test via @AfterEach

Best Practices:

Use @BeforeEach to initialize resources if needed

Use @AfterEach to clean up resources to avoid test interference

Use assertions from org.junit.jupiter.api.Assertions

Keep test methods independent

Automated Solution

JUnit

import org.junit.jupiter.api.AfterEach;
import org.junit.jupiter.api.BeforeEach;
import org.junit.jupiter.api.Test;
import java.util.ArrayList;
import java.util.List;
import static org.junit.jupiter.api.Assertions.*;

public class ResourceCleanupTest {
    private List<String> resource;

    @BeforeEach
    void setUp() {
        resource = new ArrayList<>();
        assertTrue(resource.isEmpty(), "Resource should be empty before each test");
    }

    @Test
    void testAddItemOne() {
        resource.add("item1");
        assertEquals(1, resource.size(), "Resource should contain one item");
        assertTrue(resource.contains("item1"), "Resource should contain 'item1'");
    }

    @Test
    void testAddItemTwo() {
        resource.add("item2");
        assertEquals(1, resource.size(), "Resource should contain one item");
        assertTrue(resource.contains("item2"), "Resource should contain 'item2'");
    }

    @AfterEach
    void tearDown() {
        resource.clear();
        assertTrue(resource.isEmpty(), "Resource should be empty after each test");
    }
}

This test class demonstrates the use of @AfterEach in JUnit 5 to clean up resources after each test method.

setUp() method annotated with @BeforeEach initializes the resource and asserts it is empty before each test.

Two test methods add different items to the resource and verify the additions.

The @AfterEach method tearDown() clears the resource and asserts it is empty after each test, ensuring no leftover data affects other tests.

This pattern keeps tests independent and avoids side effects.

Common Mistakes - 3 Pitfalls

Not clearing or resetting shared resources after each test

Using @AfterAll instead of @AfterEach for cleanup

Modifying resources in @AfterEach without proper initialization in @BeforeEach

Bonus Challenge

Now add a third test method that adds two items and verify the resource is still cleared after the test

Show Hint

Practice

1. What is the main purpose of a method annotated with @AfterEach in JUnit?

easy

A. To define a test method itself

B. To run code before any test methods start

C. To run cleanup code after each test method executes

D. To skip a test method during execution

Solution

1. Step 1: Understand the role of @AfterEach

   The @AfterEach annotation marks methods that run after every test method to clean up or reset state.

2. Step 2: Compare options with this role

   Only To run cleanup code after each test method executes correctly describes this cleanup role after each test method.

3. Final Answer:

   To run cleanup code after each test method executes -> Option C

4. Quick Check:

   @AfterEach = cleanup after tests [OK]

Hint: Remember: @AfterEach runs after every test method [OK]

Common Mistakes:

• Confusing @AfterEach with @BeforeEach
• Thinking @AfterEach defines test methods
• Assuming @AfterEach skips tests

2. Which of the following is the correct method signature for a method annotated with @AfterEach in JUnit?

easy

A. public int cleanup()

B. public void cleanup()

C. public void cleanup(String param)

D. public static void cleanup()

Solution

1. Step 1: Recall method requirements for @AfterEach

   Methods with @AfterEach must be void, no-argument, and instance methods (not static).

2. Step 2: Check each option

   public void cleanup() matches: public, void return, no parameters, instance method. Options B and C have wrong return type or parameters. public static void cleanup() is static, which is not allowed.

3. Final Answer:

   public void cleanup() -> Option B

4. Quick Check:

   @AfterEach method = void, no-args, non-static [OK]

Hint: @AfterEach methods are void, no parameters, non-static [OK]

Common Mistakes:

• Adding parameters to @AfterEach methods
• Making @AfterEach methods static
• Using non-void return types

3. Consider the following JUnit test class snippet:

class ExampleTest {
  int count = 0;

  @AfterEach
  void reset() {
    count = 0;
  }

  @Test
  void testIncrement() {
    count++;
    assertEquals(1, count);
  }

  @Test
  void testDecrement() {
    count--;
    assertEquals(-1, count);
  }
}

What will be the result when running both tests?

medium

A. Both tests pass because count resets after each test

B. Both tests fail because count is shared and not reset

C. testIncrement passes, testDecrement fails

D. testIncrement fails, testDecrement passes

Solution

1. Step 1: Understand @AfterEach effect on count

   The reset() method sets count to 0 after each test method runs, so each test starts fresh.

2. Step 2: Analyze each test

   In testIncrement(), count increments from 0 to 1, assertion matches. In testDecrement(), count decrements from 0 to -1, assertion matches. Both pass.

3. Final Answer:

   Both tests pass because count resets after each test -> Option A

4. Quick Check:

   @AfterEach resets state = tests independent [OK]

Hint: @AfterEach resets variables so tests don't affect each other [OK]

Common Mistakes:

• Assuming count keeps value between tests
• Forgetting @AfterEach runs after each test
• Confusing @AfterEach with @BeforeEach

4. Identify the error in this JUnit test class:

class SampleTest {

  @AfterEach
  public static void cleanup() {
    System.out.println("Cleaning up");
  }

  @Test
  void testSomething() {
    assertTrue(true);
  }
}

medium

A. The @AfterEach method should not be static

B. The @AfterEach method must return boolean

C. The @Test method must be static

D. The @AfterEach method must have parameters

Solution

1. Step 1: Check @AfterEach method signature rules

   @AfterEach methods must be instance methods (non-static), void, and no-argument.

2. Step 2: Identify the error in the code

   The method cleanup() is declared static, which violates the rule.

3. Final Answer:

   The @AfterEach method should not be static -> Option A

4. Quick Check:

   @AfterEach methods cannot be static [OK]

Hint: @AfterEach methods must be instance, not static [OK]

Common Mistakes:

• Making @AfterEach methods static
• Adding parameters to @AfterEach methods
• Changing return type from void

5. You have a test class where each test opens a database connection. You want to ensure the connection closes after each test to avoid resource leaks. Which is the best way to do this using @AfterEach?

hard

A. Do not close the connection; let JVM handle it

B. Call connection.close() at the start of each test method

C. Use @BeforeEach to close the connection before tests

D. Annotate a method that calls connection.close() with @AfterEach

Solution

1. Step 1: Understand resource cleanup best practice

   Resources like database connections should be closed after each test to avoid leaks and interference.

2. Step 2: Apply @AfterEach for cleanup

   Using a method annotated with @AfterEach to close the connection ensures it happens after every test, keeping tests independent and safe.

3. Final Answer:

   Annotate a method that calls connection.close() with @AfterEach -> Option D

4. Quick Check:

   @AfterEach = cleanup resources after tests [OK]

Hint: Use @AfterEach to close resources after each test [OK]

Common Mistakes:

• Closing resources before tests instead of after
• Not closing resources causing leaks
• Relying on JVM to close resources automatically