Custom extensions in JUnit - Deep Dive

Overview - Custom extensions

What is it?

Custom extensions in JUnit are ways to add your own code that runs during test execution. They let you change how tests start, finish, or handle special cases. This helps you add features like setup, cleanup, or special checks without repeating code in every test. Extensions make tests more flexible and powerful.

Why it matters

Without custom extensions, you would write the same setup or cleanup code in every test, making tests longer and harder to maintain. Custom extensions solve this by letting you write reusable code that runs automatically. This saves time, reduces mistakes, and helps keep tests clean and organized.

Where it fits

Before learning custom extensions, you should know basic JUnit test writing and lifecycle methods like @BeforeEach and @AfterEach. After mastering extensions, you can explore advanced testing topics like parameterized tests, test templates, and integrating with other tools or frameworks.

Mental Model

Core Idea

Custom extensions let you plug your own code into JUnit’s test lifecycle to add or change behavior automatically.

Think of it like...

It’s like adding a smart assistant to your daily routine who automatically prepares your workspace before you start and cleans up after you finish, so you don’t have to do it yourself every time.

┌───────────────┐
│ Test Runner   │
├───────────────┤
│ Custom       │
│ Extensions   │
│ (hooks)      │
├───────────────┤
│ Test Methods  │
└───────────────┘

Flow:
Test Runner → Custom Extensions hooks → Test Methods execution

Build-Up - 7 Steps

1

Foundation

JUnit Extension Basics

Concept: Learn what a JUnit extension is and how it fits into test execution.

JUnit extensions are classes that implement extension interfaces like BeforeEachCallback or AfterEachCallback. These interfaces let you run code before or after each test method automatically. You register extensions with @ExtendWith annotation on test classes or methods.

Result

Tests run with extra code before or after each test method without changing the test code itself.

Understanding that extensions hook into the test lifecycle helps you see how to add reusable behavior cleanly.

2

Foundation

Registering Extensions

Concept: How to apply extensions to tests using annotations or programmatic registration.

You can register an extension by annotating a test class or method with @ExtendWith(MyExtension.class). Alternatively, you can register extensions programmatically using the ExtensionContext or via the JUnit Platform configuration.

Result

JUnit knows to run your extension code during test execution for the annotated tests.

Knowing registration methods lets you control which tests get extended behavior.

3

Intermediate

Common Extension Interfaces

🤔Before reading on: do you think extensions can only run code before tests, or also after? Commit to your answer.

Concept: Explore the main extension interfaces and when they run your code.

JUnit provides interfaces like BeforeEachCallback (runs before each test), AfterEachCallback (runs after each test), BeforeAllCallback, AfterAllCallback, TestExecutionExceptionHandler (handles exceptions), and ParameterResolver (injects parameters). Implementing these lets you customize test behavior at different points.

Result

You can run code at precise moments in the test lifecycle, like setup, teardown, or error handling.

Understanding these interfaces unlocks the full power of extensions to control test flow.

4

Intermediate

Creating a Simple Logging Extension

🤔Before reading on: do you think an extension can access test method names? Commit to your answer.

Concept: Build a basic extension that logs test start and end events.

Implement BeforeEachCallback and AfterEachCallback interfaces. In beforeEach(), print the test method name starting. In afterEach(), print test method name finished. Register this extension with @ExtendWith on a test class. Run tests to see logs automatically.

Result

Console shows messages before and after each test method runs, without changing test code.

Knowing extensions can access test details lets you add useful features like logging or metrics.

5

Advanced

Parameter Injection with Extensions

🤔Before reading on: can extensions provide custom objects as test method parameters? Commit to your answer.

Concept: Use ParameterResolver interface to inject custom parameters into test methods.

Implement ParameterResolver with supportsParameter() to check parameter type and resolveParameter() to provide the object. Annotate test methods to accept the custom parameter. Register the extension. When tests run, JUnit calls your resolver to supply the parameter automatically.

Result

Tests receive custom objects automatically, enabling flexible and reusable test data setup.

Understanding parameter injection lets you write cleaner tests without manual setup.

6

Advanced

Handling Exceptions with Extensions

🤔Before reading on: do you think extensions can catch and modify test exceptions? Commit to your answer.

Concept: Use TestExecutionExceptionHandler to intercept exceptions thrown by tests.

Implement TestExecutionExceptionHandler interface with handleTestExecutionException(). Inside, you can log, modify, or suppress exceptions. Register this extension. When a test throws, your handler runs, letting you customize error handling.

Result

Tests can have centralized error handling logic, improving test diagnostics or recovery.

Knowing you can control exceptions helps build robust test suites that handle failures gracefully.

7

Expert

Combining Multiple Extensions and Ordering

🤔Before reading on: do you think multiple extensions run in a fixed order or random? Commit to your answer.

Concept: Learn how to use multiple extensions together and control their execution order.

You can apply multiple extensions by listing them in @ExtendWith or registering them programmatically. Use @Order annotation or implement Ordered interface to define execution priority. JUnit runs extensions in order, so setup and teardown happen predictably. Misordering can cause subtle bugs.

Result

Complex test behaviors can be composed safely with predictable extension execution order.

Understanding extension ordering prevents conflicts and ensures reliable test lifecycle management.

Under the Hood

JUnit discovers extensions via annotations or configuration before running tests. It creates instances of extension classes and calls their callback methods at specific lifecycle points. The ExtensionContext object provides test details and state. Extensions run inside the test thread, allowing them to modify behavior or inject data dynamically.

Why designed this way?

JUnit’s extension model was designed to be flexible and modular, avoiding rigid inheritance hierarchies. Interfaces let developers add only needed features. The callback pattern fits well with JUnit’s lifecycle and keeps tests clean. Alternatives like subclassing were less flexible and harder to maintain.

┌─────────────────────┐
│ Test Runner         │
│                     │
│  ┌───────────────┐  │
│  │ Extension     │  │
│  │ Manager       │  │
│  └──────┬────────┘  │
│         │           │
│  ┌──────▼────────┐  │
│  │ Extension     │  │
│  │ Instances     │  │
│  └──────┬────────┘  │
│         │           │
│  ┌──────▼────────┐  │
│  │ Test Methods  │  │
│  └──────────────┘  │
└─────────────────────┘

Flow:
Test Runner → Extension Manager → Extension Instances → Test Methods

Myth Busters - 4 Common Misconceptions

Quick: do you think extensions run in parallel with tests? Commit to yes or no.

Common Belief: Extensions run in parallel threads alongside tests to speed up execution.

Reality: Extensions run synchronously in the same thread as the test method to maintain order and state consistency.

Why it matters: Assuming parallel execution can cause thread-safety bugs or unexpected behavior in extensions.

Quick: do you think extensions can modify test method code directly? Commit to yes or no.

Common Belief: Extensions can change the actual code inside test methods before running.

Reality: Extensions cannot modify test method code; they only run additional code before, after, or around tests.

Why it matters: Expecting code modification leads to confusion about extension capabilities and misuse.

Quick: do you think all extensions apply globally to all tests by default? Commit to yes or no.

Common Belief: Once an extension is created, it automatically applies to every test in the project.

Reality: Extensions only apply where explicitly registered via annotations or configuration.

Why it matters: Assuming global application can cause unexpected test behavior or missed extension effects.

Quick: do you think extension ordering is always guaranteed without annotations? Commit to yes or no.

Common Belief: JUnit runs multiple extensions in a fixed order without needing explicit ordering.

Reality: Without @Order or Ordered interface, extension execution order is undefined and may vary.

Why it matters: Ignoring ordering can cause flaky tests or setup/teardown conflicts.

Expert Zone

1

Extensions can share state via the ExtensionContext’s Store, enabling communication between callbacks.

2

ParameterResolvers can be combined with other extensions to create complex injection scenarios, but require careful supportsParameter logic.

3

Exception handlers can rethrow exceptions wrapped in custom types to integrate with external reporting tools.

When NOT to use

Avoid custom extensions for very simple setup or teardown tasks better handled by @BeforeEach/@AfterEach methods. For complex mocking or stubbing, use dedicated libraries like Mockito. If you need to modify test discovery or execution globally, consider JUnit Platform plugins instead.

Production Patterns

In real projects, extensions are used for logging test metrics, managing external resources (like databases), injecting test data, handling flaky tests by retrying, and integrating with CI/CD pipelines for enhanced reporting.

Connections

Aspect-Oriented Programming (AOP)

Custom extensions in JUnit are similar to AOP advice that runs code before or after methods.

Knowing AOP helps understand how extensions weave additional behavior around core logic without changing it.

Middleware in Web Servers

JUnit extensions act like middleware layers that intercept and modify requests (tests) as they pass through.

Understanding middleware clarifies how extensions can chain and order behaviors during test execution.

Event Listeners in GUI Programming

Extensions listen to test lifecycle events like listeners respond to user actions.

Recognizing this event-driven model helps grasp how extensions react to test phases dynamically.

Common Pitfalls

#1 Registering extensions globally without control causes unexpected side effects.

Wrong approach:

@ExtendWith(MyExtension.class) on a base test class used everywhere without filtering.

Correct approach:

Use @ExtendWith only on specific test classes or methods that need the extension.

Root cause:

Misunderstanding extension scope leads to applying behavior where it’s not wanted.

#2 Not implementing supportsParameter correctly causes parameter injection failures.

Wrong approach:

public boolean supportsParameter(ParameterContext pc, ExtensionContext ec) { return true; }

Correct approach:

public boolean supportsParameter(ParameterContext pc, ExtensionContext ec) { return pc.getParameter().getType() == MyType.class; }

Root cause:

Ignoring parameter type checks causes extensions to claim unsupported parameters.

#3 Ignoring extension execution order leads to flaky tests.

Wrong approach:

Multiple extensions applied without @Order annotations or Ordered interface.

Correct approach:

Annotate extensions with @Order or implement Ordered to define execution priority.

Root cause:

Assuming JUnit orders extensions by default causes unpredictable lifecycle behavior.

Key Takeaways

Custom extensions let you add reusable code that runs automatically during JUnit test execution.

They hook into specific lifecycle moments like before or after tests, or when exceptions occur.

Extensions must be registered explicitly and can be combined with controlled execution order.

They enable cleaner tests by separating setup, teardown, logging, parameter injection, and error handling.

Understanding extension internals and limitations helps avoid common mistakes and build robust test suites.

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