Custom extensions in JUnit - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ Predict Output

intermediate

Output of a JUnit 5 custom extension with BeforeEachCallback

What will be printed when this JUnit 5 test class runs with the custom extension?

JUnit

import org.junit.jupiter.api.extension.*;
import org.junit.jupiter.api.*;

class MyExtension implements BeforeEachCallback {
    @Override
    public void beforeEach(ExtensionContext context) {
        System.out.println("Setup before each test");
    }
}

@ExtendWith(MyExtension.class)
class SampleTest {
    @Test
    void testOne() {
        System.out.println("Running testOne");
    }
    @Test
    void testTwo() {
        System.out.println("Running testTwo");
    }
}

A Running testOne\nRunning testTwo\nSetup before each test\nSetup before each test

B Running testOne\nSetup before each test\nRunning testTwo\nSetup before each test

C Setup before each test\nSetup before each test\nRunning testOne\nRunning testTwo

D Setup before each test\nRunning testOne\nSetup before each test\nRunning testTwo

💡 Hint

Remember that BeforeEachCallback runs before each test method.

The custom extension implements BeforeEachCallback, so its beforeEach method runs before each test method. Therefore, the message 'Setup before each test' prints before each test's output.

❓ assertion

intermediate

Correct assertion to verify extension invocation count

Given a custom JUnit 5 extension that increments a counter each time beforeEach is called, which assertion correctly verifies that the counter equals 3 after running 3 tests?

JUnit

class CountingExtension implements BeforeEachCallback {
    static int count = 0;
    @Override
    public void beforeEach(ExtensionContext context) {
        count++;
    }
}

// After running 3 tests, check count value

A assertEquals(3, CountingExtension.count);

B assertTrue(CountingExtension.count == 3);

C assertFalse(CountingExtension.count != 3);

D assertEquals(CountingExtension.count, 3);

💡 Hint

Use the standard JUnit assertion method with expected value first.

assertEquals(expected, actual) expects the expected value as the first argument. Option A uses this correctly. Option A reverses arguments which is not recommended and may cause confusing error messages.

🔧 Debug

advanced

Identify the error in this custom extension implementation

What error will occur when running this JUnit 5 extension code?

JUnit

import org.junit.jupiter.api.extension.*;

public class FaultyExtension implements BeforeAllCallback {
    @Override
    public void beforeAll(ExtensionContext context) {
        System.out.println("Before all tests");
    }

    public void beforeEach(ExtensionContext context) {
        System.out.println("Before each test");
    }
}

A No error; both methods run correctly

B beforeEach method is never called because it does not override any interface method

C Compilation error due to missing @Override on beforeEach method

D Runtime error: Method beforeEach causes IllegalStateException

💡 Hint

Check which interfaces the class implements and which methods are called by JUnit.

The class implements BeforeAllCallback, so only beforeAll is called by JUnit. The beforeEach method is a plain method without @Override and not part of any interface implemented, so it is never called.

❓ framework

advanced

Which JUnit 5 extension point allows modifying test instance before each test?

You want to create a custom extension that modifies the test class instance before each test method runs. Which extension point should you implement?

A TestInstancePostProcessor

B TestExecutionExceptionHandler

C BeforeAllCallback

D BeforeEachCallback

💡 Hint

Consider which extension point allows you to access and modify the test instance itself.

TestInstancePostProcessor allows you to modify the test instance after it is created but before any tests run. BeforeEachCallback runs before each test but does not provide the test instance for modification.

🧠 Conceptual

expert

Effect of registering multiple extensions with conflicting callbacks

If two JUnit 5 extensions both implement BeforeEachCallback and are registered on the same test class, what is the expected behavior during test execution?

A JUnit throws an exception due to conflicting extensions

B Only the first registered extension's beforeEach method is called

C Both extensions' beforeEach methods are called in registration order before each test

D Only the last registered extension's beforeEach method is called

💡 Hint

Think about how JUnit 5 handles multiple extensions implementing the same callback.

JUnit 5 calls all registered extensions' callback methods in the order they are registered. So both beforeEach methods run before each test.

Practice

1. What is the main purpose of using a custom extension in JUnit with @ExtendWith?

easy

A. To generate test reports in different formats

B. To write test cases faster by skipping assertions

C. To change the Java version used by the test runner

D. To add reusable code that runs before or after tests automatically

Solution

1. Step 1: Understand the role of custom extensions

   Custom extensions allow adding reusable code that hooks into the test lifecycle, such as setup or teardown actions.

2. Step 2: Recognize the use of @ExtendWith

   The annotation @ExtendWith applies these extensions to tests so the extra code runs automatically before or after tests.

3. Final Answer:

   To add reusable code that runs before or after tests automatically -> Option D

4. Quick Check:

   Custom extensions = reusable lifecycle code [OK]

Hint: Remember @ExtendWith adds reusable code around tests [OK]

Common Mistakes:

• Thinking extensions skip assertions
• Confusing extensions with Java version settings
• Assuming extensions generate reports

2. Which of the following is the correct syntax to apply a custom extension class named MyExtension to a JUnit 5 test class?

easy

A. @ExtendWith(MyExtension.class)

B. @UseExtension(MyExtension)

C. @EnableExtension(MyExtension.class)

D. @ApplyExtension(MyExtension.class)

Solution

1. Step 1: Recall the correct annotation for extensions

   JUnit 5 uses @ExtendWith to apply extensions to test classes or methods.

2. Step 2: Check the syntax for specifying the extension class

   The extension class must be passed as a class literal with .class, so @ExtendWith(MyExtension.class) is correct.

3. Final Answer:

   @ExtendWith(MyExtension.class) -> Option A

4. Quick Check:

   @ExtendWith + .class = correct syntax [OK]

Hint: Use @ExtendWith with .class for extension classes [OK]

Common Mistakes:

• Omitting .class after the extension name
• Using wrong annotation names like @UseExtension
• Passing extension name without parentheses

3. Given the following extension code, what will be printed when the test runs?

public class PrintExtension implements BeforeEachCallback {
    @Override
    public void beforeEach(ExtensionContext context) {
        System.out.println("Before test: " + context.getDisplayName());
    }
}

@ExtendWith(PrintExtension.class)
public class SampleTest {
    @Test
    void testOne() {}
}

medium

A. Before test: testOne()

B. Before test: SampleTest

C. No output printed

D. Compilation error due to missing interface

Solution

1. Step 1: Understand BeforeEachCallback behavior

   The beforeEach method runs before each test method and prints the test's display name.

2. Step 2: Identify the display name for the test method

   The display name is the test method name with parentheses, so it prints "Before test: testOne()".

3. Final Answer:

   Before test: testOne() -> Option A

4. Quick Check:

   beforeEach prints test method name [OK]

Hint: BeforeEachCallback runs before each test method [OK]

Common Mistakes:

• Thinking it prints class name instead of method
• Assuming no output is printed
• Confusing interface implementation

4. Consider this extension implementation:

public class FaultyExtension implements BeforeEachCallback {
    @Override
    public void beforeEach(ExtensionContext context) {
        int x = 1 / 0;
    }
}

@ExtendWith(FaultyExtension.class)
public class TestClass {
    @Test
    void testMethod() {}
}

What will happen when running testMethod?

medium

A. The test will be skipped silently

B. The test will fail with an ArithmeticException before running

C. The test will pass normally

D. Compilation error due to division by zero

Solution

1. Step 1: Analyze the extension code for errors

   The extension's beforeEach method divides by zero, causing an ArithmeticException at runtime.

2. Step 2: Understand effect on test execution

   Since the exception occurs before the test runs, the test fails immediately with that exception.

3. Final Answer:

   The test will fail with an ArithmeticException before running -> Option B

4. Quick Check:

   Runtime error in extension causes test failure [OK]

Hint: Runtime errors in extensions fail tests before execution [OK]

Common Mistakes:

• Thinking division by zero causes compile error
• Assuming test passes despite extension error
• Believing test is skipped silently

5. You want to create a custom extension that sets up a database connection before all tests and closes it after all tests in a class. Which two JUnit 5 extension interfaces should you implement together?

hard

A. BeforeEachCallback and AfterEachCallback

B. TestInstancePostProcessor and ParameterResolver

C. BeforeAllCallback and AfterAllCallback

D. BeforeTestExecutionCallback and AfterTestExecutionCallback

Solution

1. Step 1: Identify lifecycle timing for setup/teardown

   Setting up before all tests and closing after all tests requires hooks that run once per test class, not per test method.

2. Step 2: Match interfaces to lifecycle events

   BeforeAllCallback runs before all tests in a class, and AfterAllCallback runs after all tests in a class, perfect for this use case.

3. Final Answer:

   BeforeAllCallback and AfterAllCallback -> Option C

4. Quick Check:

   BeforeAll + AfterAll = class-level setup/teardown [OK]

Hint: Use BeforeAllCallback and AfterAllCallback for class-level setup [OK]

Common Mistakes:

• Using BeforeEachCallback for class-level setup
• Confusing TestInstancePostProcessor with lifecycle callbacks
• Choosing test execution callbacks instead of all callbacks