In JUnit 5, the ParameterResolver interface was introduced to allow developers to extend JUnit’s basic functionality and write tests that take parameters of any type. Let’s look at a simple ParameterResolver implementation:

public class FooParameterResolver implements ParameterResolver {
    @Override
    public boolean supportsParameter(ParameterContext parameterContext, ExtensionContext extensionContext)
      throws ParameterResolutionException {
        // Parameter support logic
    @Override
    public Object resolveParameter(ParameterContext parameterContext, ExtensionContext extensionContext) throws ParameterResolutionException {
        // Parameter resolution logic
We can see that the class has two main methods:
supportsParameter(): determines if a parameter type is supported
resolveParameter(): returns a parameter for test execution
Because the ParameterResolutionException is thrown in the absence of a ParameterResolver implementation, we won’t get too concerned with implementation details just yet. Let’s first discuss some potential causes of the exception.
3. The ParameterResolutionException
The ParameterResolutionException can be difficult to debug, especially for those less familiar with parameterized testing.
To start, let’s define a simple Book class that we’ll write unit tests for:

public class Book {
    private String title;
    private String author;
    // Standard getters and setters
For our example, we’ll write some unit tests for Book that verify different title values. Let’s start with two very simple tests:
@Test
void givenWutheringHeights_whenCheckingTitleLength_thenTitleIsPopulated() {
    Book wuthering = new Book("Wuthering Heights", "Charlotte Bronte");
    assertThat(wuthering.getTitle().length()).isGreaterThan(0);
@Test
void givenJaneEyre_whenCheckingTitleLength_thenTitleIsPopulated() {
    Book jane = new Book("Jane Eyre", "Charlotte Bronte");
    assertThat(wuthering.getTitle().length()).isGreaterThan(0);
It’s easy to see these two tests are basically doing the same thing: setting the Book title and checking the length. We can simplify the tests by combining them into a single parameterized test. Let’s discuss some ways in which this refactoring could go wrong.
3.1. Passing Parameters to @Test Methods
Taking a very quick approach, we may believe passing parameters to the @Test annotated method is enough:
@Test
void givenTitleAndAuthor_whenCreatingBook_thenFieldsArePopulated(String title, String author) {
    Book book = new Book(title, author);
    assertThat(book.getTitle().length()).isGreaterThan(0);
    assertThat(book.getAuthor().length()).isGreaterThan(0);
The code compiles and runs, but thinking about this a little further, we should question where these parameters are coming from. Running this example, we see an exception:
org.junit.jupiter.api.extension.ParameterResolutionException: No ParameterResolver registered for parameter [java.lang.String arg0] in method ...
JUnit has no way to know what parameters to pass to the test method.

Let’s continue refactoring our unit test and look into another cause of the ParameterResolutionException.
3.2. Competing Annotations
We could supply the missing parameters with a ParameterResolver as we mentioned earlier, but let’s start more simply with a value source. Since there are two values — title and author — we can use a CsvSource to provide these values to our test.
Additionally, we’re missing a key annotation: @ParameterizedTest. This annotation informs JUnit that our test is parameterized and has test values injected into it.
Let’s make a quick attempt at refactoring:
@ParameterizedTest
@CsvSource({"Wuthering Heights, Charlotte Bronte", "Jane Eyre, Charlotte Bronte"})
@Test
void givenTitleAndAuthor_whenCreatingBook_thenFieldsArePopulated(String title, String author) {
    Book book = new Book(title, author);
    assertThat(book.getTitle().length()).isGreaterThan(0);
    assertThat(book.getAuthor().length()).isGreaterThan(0);
This seems reasonable. However, when we run the unit test, we see something interesting: two passing test runs and a third failing test run. Looking closer, we see a warning as well:
WARNING: Possible configuration error: method [...] resulted in multiple TestDescriptors [org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor, org.junit.jupiter.engine.descriptor.TestTemplateTestDescriptor].
This is typically the result of annotating a method with multiple competing annotations such as @Test, @RepeatedTest, @ParameterizedTest, @TestFactory, etc.
By adding competing test annotations, we’ve unintentionally created multiple TestDescriptors. What this means is that JUnit is still running the original @Test version of our test along with our new parameterized test.
Simply removing the @Test annotation fixes this issue.
3.3. Working with a ParameterResolver
Earlier, we discussed a simple example of a ParameterResolver implementation. Now that we have a working test, let’s introduce a BookParameterResolver:

public class BookParameterResolver implements ParameterResolver {
    @Override
    public boolean supportsParameter(ParameterContext parameterContext, ExtensionContext extensionContext)
      throws ParameterResolutionException {
        return parameterContext.getParameter().getType() == Book.class;
    @Override
    public Object resolveParameter(ParameterContext parameterContext, ExtensionContext extensionContext) throws ParameterResolutionException {
        return parameterContext.getParameter().getType() == Book.class
            ? new Book("Wuthering Heights", "Charlotte Bronte")
            : null;
This is a simple example that just returns a single Book instance for testing. Now that we have a ParameterResolver to provide us with test values, we should be able to go back to the test from our first example. Again, we may try:
@Test
void givenTitleAndAuthor_whenCreatingBook_thenFieldsArePopulated(String title, String author) {
    Book book = new Book(title, author);
    assertThat(book.getTitle().length()).isGreaterThan(0);
    assertThat(book.getAuthor().length()).isGreaterThan(0);
But as we see when running this test, the same exception persists. The cause is slightly different though — now that we have a ParameterResolver, we still need to tell JUnit how to use it.
Fortunately, this is as simple as adding the @ExtendWith annotation to the outer class that contains our test methods:
@ExtendWith(BookParameterResolver.class)
public class BookUnitTest {
    @Test
    void givenTitleAndAuthor_whenCreatingBook_thenFieldsArePopulated(String title, String author) {
        // Test contents...
    // Other unit tests
Running this again, we see a successful test execution.
4. Conclusion
In this article, we discussed JUnit 5’s ParameterResolutionException and how missing or competing configurations can cause this exception. As always, all of the code for the article can be found over on GitHub.
Partner – Bellsoft – NPI EA (cat = Spring)


Looking for the ideal Linux distro for running modern Spring
apps in the cloud?
Meet Alpaquita Linux: lightweight, secure, and powerful
enough to handle heavy workloads.
This distro is specifically designed for running Java
apps. It builds upon Alpine and features significant
enhancements to excel in high-density container environments while
meeting enterprise-grade security standards.
Specifically, the container image size is ~30% smaller than
standard options, and it consumes up to 30% less RAM:
Alpaquita Containers now.

Partner – Bellsoft – NPI EA (cat = Spring)


Just published a new writeup on how to run a standard Java/Boot
application as a Docker container, using the Liberica JDK on top of
Alpaquita Linux:
Spring Boot Application on Liberica Runtime Container.

Partner – Aegik AB – NPI EA (tag = SQL)


Slow MySQL query performance is all too common. Of course
it is.
The Jet Profiler was built entirely for MySQL, so it's
fine-tuned for it and does advanced everything with relaly minimal
impact and no server changes.
out the Profiler

Partner – Codium – NPI EA (cat = Testing)


Explore the secure, reliable, and high-performance Test
Execution Cloud built for scale. Right in your IDE:
CodiumAI. Meaningful Code Tests for Busy Devs

Basically, write code that works the way you meant it to.
Course – LS – All

Get started with Spring Boot and with core Spring,
through the Learn Spring course:
>> CHECK OUT THE
COURSE
res – REST with Spring (eBook) (everywhere)

Learning to build your API

with Spring?
Download the E-book
Starting to test with Mockito?
Download the Guide
eBook – Video Security – NPI EA (cat=Spring Security)

Security basics for a REST API
access to the video
eBook – Persistence – NPI EA (cat=Persistence)

Download
the E-book
eBook – Guide Junit – NPI (tag=JUnit/JUnit 5)

Quick Guide to Take Advantage of JUnit
Download the E-book