Introduce SPI for generating display names

[nipafx]

In many cases the strings passed to @DisplayName are just a prettified version of the class/method name, e.g.:

@DisplayName("List")
class ListTest {
    @Nested
    @DisplayName("when empty")
    class WhenEmpty {
        @Test
        @DisplayName("can add")
        void canAdd() {
            ...
        }
    }
}

It might be a nice-to-have if this could happen automatically, e.g.:

@DisplayName(prettify = true)
class ListTest {
    @Nested
    class WhenEmpty {
        @Test
        void canAdd() {
            ...
        }
        @Test
        @DisplayName("can't get")
        void cantGet() {
            ...
        }
    }
}

Related Issues

• Clarify and document names and display names of JUnit 4 and 5 TestDescriptors #145
• Clarify differences between DisplayName & Name throughout JUnit 5 #153
• Support simple variable expansion in display names #432
• Introduce @SuiteDisplayName in the platform suite API #1036
• DisplayName with Test feature idea #1577
• Treat enclosing class as container for static nested test classes #1589

Deliverables

• Introduce an extension for generating display names.
• Provide an out-of-the-box implementation of the extension that can be enabled via a JUnit configuration property.

[schauder]

how about making 'prettify' the default action when no explicit name is given?

[sbrannen]

I like the proposal from @schauder, and I have changed the title of this issue accordingly.

@junit-team/junit-lambda, what does the rest of the team think about making this change?

[jlink]

I think we should discuss all related issues (#145 and #153) together and make consistent changes: name, display name and unique ID have intermingled concerns which we should separate first.

[bechte]

I like the idea and also support going forward into this direction.

We should discuss in detail what prettify exactly means as we somehow set a standard for naming test methods and I know there are different styles in the community:

https://dzone.com/articles/7-popular-unit-test-naming

With this change we might make a statement which style should be used as we support it the best.

We simply should keep that in mind as we move on. Still, I support this change.

[jlink]

I'd rather not have prettification as default because there'll always be some corner cases (eg. acronyms and abbreviations) where any automatic prettification scheme will fail.

[signed]

I agree with @bechte about the different testing styles and the corner cases mentioned by @jlink. I'd prefer not having this complexity and ‘one size fits all’ naming convention in junit core.

How about providing an ExtensionPoint to provide the display name?
This way there can be a domain/style/language aware version of pretty for everyone that is willing to write an extension. By defining my own @test annotation that activates the extension by default, I can even skip the repetitive @DisplayName annotation for all of my test methods.

[jlacar]

Two edges to this sword:

1. Bad examples: https://www.youtube.com/watch?v=bpKbvb95Bv0 (from 06:17:00)
2. Good examples: http://blog.codefx.org/libraries/junit-5-basics/#Naming-Tests

YMMV but my experience often shows that more people will find and follow bad examples than the good ones. I fear the most common usage we'll end up seeing is where the display names basically repeat what the method name already says. Goodbye DRY, now we're WET (Writing Everything Twice) all over the place.

The link to the bad examples a JavaOne 2016 presentation stream, the relevant segment was given by folks from Penn State University, starting at the 06:17:00 mark. To think that these are the kind of examples that future authors of JUnit tests will learn from makes me shudder. I also would humbly point out that the JUnit 5 user guide doesn't have very good examples either.

I like the idea of automatically prettifying the names for the report through an ExtensionPoint. Are there really that many corner cases where auto-prettify would get tripped up? My teams' test naming convention follows Neal Ford's style, using underscores to separate words so an extension that auto replaces "_" with " " would have a very high, if not perfect, success rate.

[sbrannen]

In light of recent team discussions, I have renamed this issue to focus on the introduction of a new extension for generating display names.

[sbrannen]

FYI: I have added a Deliverables section to this issue's description.

[sbrannen]

Regarding the camel-case converter, searching the Internet reveals lots of discussions around this topic -- for example, https://stackoverflow.com/questions/2559759/how-do-i-convert-camelcase-into-human-readable-names-in-java/2560017#2560017

[sormuras]

Thanks for the review and feedback, Sam. Pushed a second spike to #1588.

[sbrannen]

Of course, we could also come up with a hybrid camel-case + underscore style.

Actually, the more I think about it (and after having looked at the latest updates @sormuras made to his PR), I think we are actually implementing the Decorator pattern with our styles.

This leads to the following, treating style names as functions.

• default()
• underscore(default())
• camelCase(underscore(default()))

So that means that the camel-case display name generator would automatically convert underscores to spaces simply be delegating to the underscore style which in turn delegates to the default style.