Junit5: Support parameter resolution in kotlin test method name

Created on 5 Jan 2020  路  6Comments  路  Source: junit-team/junit5

Hi, I would like to create a test name with resolved parameters like in Spock. Example:

@ParameterizedTest
@ValueSource(strings = ["some text", "   s o m e  "])
fun `should pass non blank string validation for: {0}`(input: String) {
    validateNonBlank(input, field)
        .throwErrorOnInvalid()
}

I know I could use:

@ParameterizedTest(name = "should pass non blank string validation for: {0}")

but I would like to avoid copy pasting.

Jupiter declined programming model

Most helpful comment

Regarding my last comment, please allow me to expound on that.

The generateDisplayNameForMethod() method in the DisplayNameGenerator SPI is used to generate a name for a method. In the case of a parameterized test, the parameterized test method itself is interpreted as a _container_ for invocations of the parameterized test.

Consequently, a DisplayNameGenerator is not applied for generation of display names for individual invocations of the parameterized test method (which is a specialization of a _test template_). On the contrary, display name generation for individual test template invocations is handled by the getDisplayName() method in the TestTemplateInvocationContext provided by a TestTemplateInvocationContextProvider.

For parameterized test methods, ParameterizedTestNameFormatter is used internally to generate display names for individual invocations based on information provided via the @ParameterizedTest annotation.

In summary, a DisplayNameGenerator can be used to generate a custom display name for a @ParameterizedTest _container_; whereas, @ParameterizedTest(name = ...) can be used to configure custom display names for individual parameterized test method _invocations_.

I hope that clarifies matters for you.

All 6 comments

BTW I tried creating my own DisplayNameGenerator it works great on simple tests (annotated with @Test) but it omits all tests annotated with @ParameterizedTest. Is it intentional behavior?

I tested it on versions 5.6.0-M1 and 5.5.2

BTW I tried creating my own DisplayNameGenerator it works great on simple tests (annotated with @Test) but it omits all tests annotated with @ParameterizedTest. Is it intentional behavior?

The example.DisplayNameGeneratorDemo.A_year_is_a_leap_year.if_it_is_one_of_the_following_years(int) parameterized test in the User Guide demonstrates this working.

So, if you are experiencing otherwise, please provide an example that demonstrates that.

In any case, a custom DisplayNameGenerator is indeed the correct approach for achieving your goal.

Regarding my last comment, please allow me to expound on that.

The generateDisplayNameForMethod() method in the DisplayNameGenerator SPI is used to generate a name for a method. In the case of a parameterized test, the parameterized test method itself is interpreted as a _container_ for invocations of the parameterized test.

Consequently, a DisplayNameGenerator is not applied for generation of display names for individual invocations of the parameterized test method (which is a specialization of a _test template_). On the contrary, display name generation for individual test template invocations is handled by the getDisplayName() method in the TestTemplateInvocationContext provided by a TestTemplateInvocationContextProvider.

For parameterized test methods, ParameterizedTestNameFormatter is used internally to generate display names for individual invocations based on information provided via the @ParameterizedTest annotation.

In summary, a DisplayNameGenerator can be used to generate a custom display name for a @ParameterizedTest _container_; whereas, @ParameterizedTest(name = ...) can be used to configure custom display names for individual parameterized test method _invocations_.

I hope that clarifies matters for you.

Team Decision: Due to the aforementioned custom display name support offered by DisplayNameGenerator and @ParameterizedTest(name = ...), we do not currently plan to provide explicit support for placeholders in Kotlin (or Groovy) parameterized test method names.

If you feel the existing support is inadequate, please provide further input.

In the interim, we are closing this issue.

Thanks for clarifying things it out.

When it comes for placeholders in Kotlin (or Groovy), I simply think it would be a great benefit to reuse the method name as a template to generate display names for individual invocations.

Maybe it's already possible with Extensions. I'll check it up in spare time. For now it's all from me. Thanks a lot.

Was this page helpful?
0 / 5 - 0 ratings