Allow Test Classes to Implement DisplayNameGenerator for Inherited Naming Behavior

[sljinlet]

Currently, JUnit 5 requires tests to specify a DisplayNameGenerator either:

• Globally via the junit.jupiter.displayname.generator system property.

• On a per-class basis using @DisplayNameGeneration(SomeGenerator.class).
  This request proposes allowing test classes to implement or extend DisplayNameGenerator, enabling a more natural and scalable way to define test naming conventions, particularly when using a shared parent class for tests.

Use Case

In large test suites, it's common to have a base test class that all test classes inherit from. This base class often includes shared configuration and behavior. It would be useful if test classes could inherit a DisplayNameGenerator from the base class, rather than requiring explicit annotations on each test class.

For example:

import org.junit.jupiter.api.DisplayNameGenerator;
import java.lang.reflect.Method;

public class FetchTestSuite implements DisplayNameGenerator {

    @Override
    public String generateDisplayNameForClass(Class<?> testClass) {
        return "Suite: " + testClass.getSimpleName();
    }

    @Override
    public String generateDisplayNameForMethod(Class<?> testClass, Method testMethod) {
        return "Test: " + testMethod.getName().replace("_", " ");
    }
}

Any test class extending FetchTestSuite would automatically inherit the display name generation logic:

import org.junit.jupiter.api.Test;

public class MyTest extends FetchTestSuite {

    @Test
    void some_test_case() {
        // Expected display name: "Test: some test case"
    }
}

If a subclass wants a different naming strategy, it can simply override the methods:

public class MyTest extends FetchTestSuite {
    @Override
    public String generateDisplayNameForMethod(Class<?> testClass, Method testMethod) {
        return "🔹 Custom Test: " + testMethod.getName();
    }
}

Current Workarounds

Currently, to achieve this behavior, we must:

• Manually annotate every test class with @DisplayNameGeneration(FetchTestSuite.class).
• Use an extension that applies System.setProperty("junit.jupiter.displayname.generator", SomeGenerator.class.getName()) before tests run (which is an indirect solution).

Proposed Solution

JUnit should automatically check whether a test class implements or extends DisplayNameGenerator, and if so, use it as the display name generator instead of requiring an annotation.

Suggested logic:

If a test class is annotated with @DisplayNameGeneration, use the specified generator, else, if the test class implements DisplayNameGenerator, use it. else, fallback to the default behavior.

Benefits
✅ Less Boilerplate – No need for redundant annotations on every test class.
✅ Follows Normal Java Inheritance – Subclasses can override naming logic as needed.
✅ More Flexible and Scalable – Large test suites with shared behavior benefit from a centralized naming strategy.
✅ Backwards Compatible – This change does not break existing behavior unless the author has already had a test class implement DisplayNameGenerator, at which point they're likely to want this enhancement to allow them to remove extra code.

[marcphilipp]

Manually annotate every test class with @DisplayNameGeneration(FetchTestSuite.class).

Since the annotation is inherited, it should suffice to annotate the base class with @DisplayNameGeneration(FetchTestSuite.class). If subclasses want to override the behavior, they can declare @DisplayNameGeneration(MyTest.class).

@sljinlet Have you tried that?

[sljinlet]

I am not having a problem getting the behavior I want. All of my test classes inherit from the same parent class. I want that parent class to mandate the name generation behavior. I understand that there are multiple ways of getting this behavior, but they all involve adding annotations. In the process of implementing this behavior, I recognized that it might be nice if the code could deduce the behavior I want from the fact that my test class implements DisplayNameGenerator. What other reason would I have for applying this interface in this way besides wanting that naming behavior applied to tests that subclass from this class?

So this works:

@DisplayNameGeneration(FetchTestSuite.class)
public class FetchTestSuite extends TestSuite implements DisplayNameGenerator {

I'm simply proposing that the annotation here be made redundant. What other reason would I have for having this class implement DisplayNameGenerator? I wouldn't have been surprised if this behavior already existed, as it makes such good sense to me. So to be clear, I'm proposing that the following be equivalent to the above:

public class FetchTestSuite extends TestSuite implements DisplayNameGenerator {

I am simply proposing this syntactic sugar. The lack of this feature is not impeding me in any way.

[marcphilipp]

Thanks for the clarification!

You could implement a DisplayNameGenerator like this and set it as the default via the configuration parameter:

public class IntrospectiveDisplayNameGenerator implements DisplayNameGenerator {

	@Override
	public String generateDisplayNameForClass(Class<?> testClass) {
		return getDelegate(testClass).generateDisplayNameForClass(testClass);
	}

	@Override
	public String generateDisplayNameForNestedClass(List<Class<?>> enclosingInstanceTypes, Class<?> nestedClass) {
		return getDelegate(nestedClass).generateDisplayNameForNestedClass(enclosingInstanceTypes, nestedClass);
	}

	@Override
	public String generateDisplayNameForMethod(List<Class<?>> enclosingInstanceTypes, Class<?> testClass,
			Method testMethod) {
		return getDelegate(testClass).generateDisplayNameForMethod(enclosingInstanceTypes, testClass, testMethod);
	}

	private static DisplayNameGenerator getDelegate(Class<?> testClass) {
		if (DisplayNameGenerator.class.isAssignableFrom(testClass)) {
			return (DisplayNameGenerator) ReflectionSupport.newInstance(testClass);
		}
		return DisplayNameGenerator.getDisplayNameGenerator(Standard.class);
	}
}

However, as this example illustrates doing so requires an instance of the test class which is only created later during execution, not during discovery. This implementation assumes the test class has a default constructor which isn't necessarily the case (for example, when writing a @ParameterizedClass).