Junit5: Default display name for methods appends empty parentheses

[Sam-Kruglov]

In JUnit Jupiter 5.5.1 using Kotlin 1.3.41:

@Nested
inner class `assign to group` {
    @Test
    fun `failure -- stop`() {
    }
    @Test
    fun assigned() {
    }
}

Results in the following display names:

assign to group
  failure -- stop()
  assigned()

While I expect it without parentheses:

assign to group
  failure -- stop
  assigned

[sbrannen]

That's actually to be expected, since it is the default behavior for display names based on technical method names, where a Kotlin name like that is in fact the "technical name" of the method.

To remove the trailing parentheses, you could implement a custom DisplayNameGenerator.

For example, org.junit.jupiter.api.DisplayNameGenerator.ReplaceUnderscores removes the trailing parentheses if the method does not have a formal parameter list. See org.junit.jupiter.api.DisplayNameGenerator.ReplaceUnderscores.generateDisplayNameForMethod(Class<?>, Method) for details.

[pauldingemans]

It is debatable whether the issue should be linked to Kotlin functions specified between back ticks solely. It might as well be applied to java methods without parameters as well.

It seems to be a design decision (backward compatibility?) that the Standard DisplayNameGenerator displays "()" for an empty parameter list as that has been the way methods without parameter list (and without DisplayName annotations) have been displayed:

    /**
     * Standard {@code DisplayNameGenerator}.
     *
     * <p>This implementation matches the standard display name generation
     * behavior in place since JUnit Jupiter 5.0 was released.
     */

It can also be argued that since this is still an experimental feature, that a test name will end only with a list of parameters between parentheses when applicable.

[marcphilipp]

I think we could provide a new built-in DisplayNameGenerator that would be like Standard but remove () from the end of method display names. Users could then use it as their default in junit-platform.properties.

[sbrannen]

It can also be argued that since this is still an experimental feature, that a test name will end only with a list of parameters between parentheses when applicable.

The default behavior since 5.0 is not experimental but rather stable.

I think we could provide a new built-in DisplayNameGenerator that would be like Standard but remove () from the end of method display names. Users could then use it as their default in junit-platform.properties.

Yes, I think that sounds reasonable.

[marcphilipp]

What would we call it? Parenthesesless is rather a mouthful.

[sormuras]

What about Kenerator?

[pauldingemans]

As usual naming is hard. Also it is only a small difference compared with the standard. I propose to call it something like Plain or Simple.

[Sam-Kruglov]

Have the with kotlin in it. So that it is clear what is it for

[pauldingemans]

Have the with kotlin in it. So that it is clear what is it for

It is not strictly bound to Kotlin. I would find it nice in a Java context as well.

[Sam-Kruglov]

Is that possible to know at runtime if we are dealing with Kotlin so that it will be applied automatically? Or is that a big overhead to just apply that logic always, since it would do nothing for other cases. So that I don't need to edit any properties

[Sam-Kruglov]

I don't think Java has issues with parentheses in the end or does it?

[sbrannen]

Neither Java nor Kotlin have issues with parentheses at the end of the display name in this context: the display name is only used for reporting purposes. Thus there is nothing language-specific about it.

As @pauldingemans stated, the new display name generator could be used for any source JVM language. Thus, the name should not imply anything about a particular language.

As @pauldingemans recommended, something like Plain* or Simple* might serve the purpose well.

Is that possible to know at runtime if we are dealing with Kotlin so that it will be applied automatically? Or is that a big overhead to just apply that logic always, since it would do nothing for other cases. So that I don't need to edit any properties

IIRC, We don't currently have any code in place that does something different based on the JVM language used to implement the test class, so I don't think we should start adding anything along those lines.

@junit-team/junit-lambda, thoughts?

[sbrannen]

Team Decision: Implement a new DisplayNameGenerator named Simple that extends Standard and excludes the parentheses after the method name if the method does not accept any parameters (analogous to the hasParameters(...) support in the ReplaceUnderscores generator).