Why extensions customize JUnit behavior - Challenge Your Understanding

Challenge - 5 Problems

🧠 Conceptual

intermediate

Purpose of JUnit Extensions

Why do developers use extensions to customize JUnit behavior?

A To add new features like custom test lifecycle events and parameter injection

B To disable all test execution and only generate reports

C To change the Java language syntax used in test classes

D To replace JUnit's core assertion methods with third-party ones

💡 Hint

Think about how extensions help tests do more than just run assertions.

JUnit extensions allow adding features such as custom setup/teardown, injecting parameters, or modifying test execution flow, enhancing test flexibility.

❓ Predict Output

intermediate

Output of a JUnit Extension Modifying Test Execution

Given the following JUnit 5 extension and test, what will be the output when the test runs?

JUnit

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

class SkipTestExtension implements ExecutionCondition {
    @Override
    public ConditionEvaluationResult evaluateExecutionCondition(ExtensionContext context) {
        if (context.getDisplayName().contains("skip")) {
            return ConditionEvaluationResult.disabled("Test skipped by extension");
        }
        return ConditionEvaluationResult.enabled("Test enabled");
    }
}

@ExtendWith(SkipTestExtension.class)
class SampleTest {
    @Test
    void testRun() {
        System.out.println("Test is running");
    }

    @Test
    void test_skip() {
        System.out.println("This should not print");
    }
}

A No output prints because all tests are skipped

B Both 'Test is running' and 'This should not print' print

C Only 'Test is running' prints; 'test_skip' is skipped

D Compilation error due to missing override annotation

💡 Hint

Look at how the extension disables tests with 'skip' in their name.

The extension disables tests whose display name contains 'skip'. So 'test_skip' is skipped and does not print. 'testRun' runs normally.

❓ assertion

advanced

Correct Assertion to Verify Extension Behavior

Which assertion correctly verifies that a JUnit extension has injected a non-null parameter into a test method?

JUnit

@ExtendWith(MyParameterResolver.class)
void testWithParam(String param) {
    // Which assertion to use here?
}

A Assertions.assertNull(param);

B Assertions.assertEquals(null, param);

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

D Assertions.assertNotNull(param);

💡 Hint

Parameter injection should provide a valid object, not null.

To verify parameter injection worked, assert the parameter is not null. Other assertions check for null or empty, which are incorrect here.

🔧 Debug

advanced

Debugging a Failing JUnit Extension

A custom JUnit extension intended to log before each test is not printing logs. What is the most likely cause?

JUnit

public class LoggingExtension implements BeforeTestExecutionCallback {
    @Override
    public void beforeTestExecution(ExtensionContext context) {
        System.out.println("Starting test: " + context.getDisplayName());
    }
}

// Test class missing @ExtendWith(LoggingExtension.class)

A The test class is missing the @ExtendWith annotation to register the extension

B JUnit 5 does not support BeforeTestExecutionCallback interface

C System.out.println does not work inside extensions

D The extension class must implement AfterTestExecutionCallback instead

💡 Hint

Check if the extension is properly registered with the test class.

Extensions must be registered with @ExtendWith on the test class or method to be active. Without it, the extension code won't run.

❓ framework

expert

Extension Point for Custom Test Instance Post-Processing

Which JUnit 5 extension point allows modifying the test instance after it is created but before any tests run?

A BeforeAllCallback

B TestInstancePostProcessor

C ParameterResolver

D ExecutionCondition

💡 Hint

Think about the extension that can change the test object itself after creation.

TestInstancePostProcessor lets you modify or initialize the test instance after construction but before tests run. Others serve different purposes.