ParameterResolver extension in JUnit - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ Predict Output

intermediate

Output of ParameterResolver supplying a String

What is the output of the following JUnit 5 test when using a ParameterResolver that always provides the string "Hello"?

JUnit

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

class HelloParameterResolver implements ParameterResolver {
    @Override
    public boolean supportsParameter(ParameterContext pc, ExtensionContext ec) {
        return pc.getParameter().getType() == String.class;
    }

    @Override
    public Object resolveParameter(ParameterContext pc, ExtensionContext ec) {
        return "Hello";
    }
}

@ExtendWith(HelloParameterResolver.class)
public class GreetingTest {
    @Test
    void testGreeting(String greeting) {
        System.out.println(greeting);
    }
}

A null

B Test fails with ParameterResolutionException

C Compilation error

D Hello

💡 Hint

Think about what the ParameterResolver returns for the String parameter.

The ParameterResolver supports String parameters and returns "Hello". The test prints this value, so output is "Hello".

❓ assertion

intermediate

Assertion on injected parameter value

Given a ParameterResolver that injects an Integer with value 42, which assertion correctly verifies the injected value in a test method?

JUnit

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

class IntParameterResolver implements ParameterResolver {
    @Override
    public boolean supportsParameter(ParameterContext pc, ExtensionContext ec) {
        return pc.getParameter().getType() == Integer.class;
    }

    @Override
    public Object resolveParameter(ParameterContext pc, ExtensionContext ec) {
        return 42;
    }
}

@ExtendWith(IntParameterResolver.class)
public class NumberTest {
    @Test
    void testNumber(Integer number) {
        // Which assertion is correct here?
    }
}

A assertSame(42, number);

B assertTrue(number == 42);

C assertEquals(42, number);

D assertNotNull(number);

💡 Hint

Check which assertion compares values correctly for Integer objects.

assertEquals(42, number) correctly checks the Integer value. assertSame compares object references, which may fail due to boxing.

🔧 Debug

advanced

Why does ParameterResolver fail to inject?

Consider this ParameterResolver implementation that tries to inject a Double but the test method parameter is of type double (primitive). Why does the injection fail?

JUnit

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

class DoubleParameterResolver implements ParameterResolver {
    @Override
    public boolean supportsParameter(ParameterContext pc, ExtensionContext ec) {
        return pc.getParameter().getType() == Double.class;
    }

    @Override
    public Object resolveParameter(ParameterContext pc, ExtensionContext ec) {
        return 3.14;
    }
}

@ExtendWith(DoubleParameterResolver.class)
public class PiTest {
    @Test
    void testPi(double value) {
        System.out.println(value);
    }
}

A supportsParameter returns false because double primitive != Double class

B resolveParameter returns wrong type causing ClassCastException

C Test method parameter must be Double, not double

D ParameterResolver interface is not implemented correctly

💡 Hint

Check the difference between primitive types and wrapper classes in Java.

supportsParameter checks for Double.class but the parameter is primitive double, so it returns false and injection fails.

🧠 Conceptual

advanced

ParameterResolver lifecycle and caching

Which statement about the lifecycle of a ParameterResolver instance in JUnit 5 is correct?

A ParameterResolver instances are created once per test class and reused

B ParameterResolver instances are singletons shared across all tests

C JUnit creates a new ParameterResolver instance per parameter injection

D A new ParameterResolver instance is created for each test method invocation

💡 Hint

Think about how JUnit 5 manages extensions and test instances.

ParameterResolver instances are created once per test class and reused across all test methods within that class.

❓ framework

expert

Custom ParameterResolver with conditional support

You want to create a ParameterResolver that only supports parameters annotated with @InjectValue and of type String. Which implementation of supportsParameter is correct?

JUnit

import org.junit.jupiter.api.extension.*;
import java.lang.reflect.Parameter;

@interface InjectValue {}

class ConditionalParameterResolver implements ParameterResolver {
    @Override
    public boolean supportsParameter(ParameterContext pc, ExtensionContext ec) {
        return pc.isAnnotated(InjectValue.class) && pc.getParameter().getType() == String.class;
    }

    @Override
    public Object resolveParameter(ParameterContext pc, ExtensionContext ec) {
        return "Injected";
    }
}

A return pc.getParameter().getAnnotation(InjectValue.class) != null && pc.getParameter().getType().equals(String.class);

B return pc.isAnnotated(InjectValue.class) && pc.getParameter().getType() == String.class;

C return pc.getParameter().isAnnotationPresent(InjectValue.class) && pc.getParameter().getType() == String.class;

D return pc.isAnnotated(InjectValue.class) && pc.getParameter().getType().equals(String.class);

💡 Hint

Use ParameterContext methods to check annotation and type.

pc.isAnnotated checks for annotation presence correctly. Using == for Class comparison is valid. This option uses recommended API methods.

Practice

1. What is the main purpose of a ParameterResolver in JUnit 5?

easy

A. To define the order of test execution

B. To generate test reports after execution

C. To create mock objects for tests

D. To automatically provide values for test method parameters

Solution

1. Step 1: Understand ParameterResolver role

   A ParameterResolver is designed to supply values to parameters of test methods automatically, so tests don't need manual setup for those parameters.

2. Step 2: Compare with other options

   Options A, C, and D relate to other testing features but not to parameter injection.

3. Final Answer:

   To automatically provide values for test method parameters -> Option D

4. Quick Check:

   ParameterResolver = automatic parameter injection [OK]

Hint: ParameterResolver injects parameters automatically [OK]

Common Mistakes:

• Confusing ParameterResolver with test ordering
• Thinking it creates mocks automatically
• Assuming it generates reports

2. Which two methods must a class implement to be a valid ParameterResolver in JUnit 5?

easy

A. supportsParameter and resolveParameter

B. beforeEach and afterEach

C. initialize and cleanup

D. createParameter and validateParameter

Solution

1. Step 1: Recall ParameterResolver interface methods

   The ParameterResolver interface requires implementing supportsParameter to check if a parameter is supported, and resolveParameter to provide the value.

2. Step 2: Eliminate incorrect method pairs

   Options A, B, and C list methods unrelated to ParameterResolver interface.

3. Final Answer:

   supportsParameter and resolveParameter -> Option A

4. Quick Check:

   ParameterResolver methods = supportsParameter + resolveParameter [OK]

Hint: Remember: supportsParameter checks, resolveParameter provides [OK]

Common Mistakes:

• Confusing lifecycle methods with resolver methods
• Using incorrect method names
• Assuming initialization methods are required

3. Given this ParameterResolver implementation, what will be printed when the test runs?

class MyResolver implements ParameterResolver {
  public boolean supportsParameter(ParameterContext pc, ExtensionContext ec) {
    return pc.getParameter().getType() == String.class;
  }
  public Object resolveParameter(ParameterContext pc, ExtensionContext ec) {
    return "InjectedValue";
  }
}

@ExtendWith(MyResolver.class)
class TestClass {
  @Test
  void testMethod(String param) {
    System.out.println(param);
  }
}

medium

A. null

B. InjectedValue

C. Compilation error

D. Test fails with exception

Solution

1. Step 1: Analyze supportsParameter method

   It returns true only if the parameter type is String, so the test method's String param is supported.

2. Step 2: Analyze resolveParameter method

   It returns the string "InjectedValue", so this value will be injected into the test method parameter.

3. Final Answer:

   InjectedValue -> Option B

4. Quick Check:

   Parameter injection prints InjectedValue [OK]

Hint: Check supportsParameter return true for parameter type [OK]

Common Mistakes:

• Assuming parameter is null if not supported
• Expecting compilation error due to interface methods
• Thinking test fails without explicit parameter value

4. Identify the error in this ParameterResolver implementation:

class FaultyResolver implements ParameterResolver {
  public boolean supportsParameter(ParameterContext pc, ExtensionContext ec) {
    return pc.getParameter().getType() == Integer.class;
  }
  public Object resolveParameter(ParameterContext pc, ExtensionContext ec) {
    return 42;
  }
}

@ExtendWith(FaultyResolver.class)
class TestClass {
  @Test
  void testMethod(int param) {
    System.out.println(param);
  }
}

medium

A. Missing @Override annotations cause runtime error

B. resolveParameter returns wrong type

C. supportsParameter checks for Integer.class but parameter is primitive int

D. Test method parameter must be Integer, not int

Solution

1. Step 1: Check parameter type in supportsParameter

   The test method parameter is primitive int, but supportsParameter checks for Integer.class, which is the wrapper class. This causes supportsParameter to return false.

2. Step 2: Understand consequence of mismatch

   Because supportsParameter returns false, resolveParameter is never called, so the parameter is not injected, causing test failure or default value usage.

3. Final Answer:

   supportsParameter checks for Integer.class but parameter is primitive int -> Option C

4. Quick Check:

   Primitive vs wrapper mismatch breaks supportsParameter [OK]

Hint: Match primitive and wrapper types carefully in supportsParameter [OK]

Common Mistakes:

• Ignoring difference between int and Integer
• Assuming @Override annotations are mandatory
• Thinking resolveParameter type must differ

5. You want to create a ParameterResolver that injects a unique UUID string into any test method parameter of type String. Which implementation correctly achieves this and ensures a new UUID is generated for each test invocation?

hard

A. In resolveParameter, return UUID.randomUUID().toString() without caching

B. In supportsParameter, cache a UUID and return it for all calls

C. Return a fixed UUID string in resolveParameter for all tests

D. Generate UUID once in constructor and return it in resolveParameter

Solution

1. Step 1: Understand requirement for unique UUID per test

   Each test invocation should get a new UUID string, so the UUID must be generated fresh every time resolveParameter is called.

2. Step 2: Evaluate options for UUID generation

   In resolveParameter, return UUID.randomUUID().toString() without caching generates a new UUID string on each call, fulfilling the requirement. Options B, C, and D cache or fix the UUID, so they do not produce unique values per test.

3. Final Answer:

   In resolveParameter, return UUID.randomUUID().toString() without caching -> Option A

4. Quick Check:

   Generate UUID fresh in resolveParameter for uniqueness [OK]

Hint: Generate new UUID inside resolveParameter method [OK]

Common Mistakes:

• Caching UUID and returning same value every time
• Generating UUID once in constructor
• Returning fixed string instead of UUID