1. Overview
JUnit 5 introduced some powerful features, including support for parameterized testing. Writing parameterized tests can save a lot of time, and in many cases, they can be enabled with a simple combination of annotations.
However, incorrect configuration can lead to exceptions that are difficult to debug since JUnit manages many aspects of test execution behind the scenes.
One such exception is the ParameterResolutionException:
org.junit.jupiter.api.extension.ParameterResolutionException: No ParameterResolver registered for parameter ...In this tutorial, we’ll explore the causes of this exception and how to solve it.
2. JUnit 5’s ParameterResolver
To understand the cause of this exception, we first need to understand what the message is telling us we’re missing: a ParameterResolver.
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.
