@DisplayNameGeneration is not discovered on runtime enclosing type for @Nested test class

[sbrannen]

Overview

@DisplayNameGeneration is currently discovered on the current test, a superclass, or the enclosing class in which a Nested test class is declared. However, the runtime type of an enclosing instance is not always the class in which a @Nested test class is declared.

Example

The examples here are copies of those in #4130 except that @IndicativeSentencesGeneration has been moved from AbstractBaseTests to ScenarioOneTests.

abstract class AbstractBaseTests {

	@Nested
	class NestedTests {

		@Test
		void test() {
		}
	}
}

@IndicativeSentencesGeneration
class ScenarioOneTests extends AbstractBaseTests {
}

Actual Behavior

When running ScenarioOneTests, we currently see the following display names, since @IndicativeSentencesGeneration is not honored (i.e., the @DisplayNameGeneration(IndicativeSentences.class) meta-annotation is not discovered).

• ScenarioOneTests
  • NestedTests
    • test()

Expected Behavior

When running ScenarioOneTests, we would expect the following display names before #4130 is resolved.

• ScenarioOneTests
  • AbstractBaseTests, NestedTests
    • AbstractBaseTests, NestedTests, test()

When running ScenarioOneTests, we would expect the following display names after #4130 is resolved.

• ScenarioOneTests
  • ScenarioOneTests, NestedTests
    • ScenarioOneTests, NestedTests, test()

Related Issues

• DisplayNameGenerator cannot access runtime enclosing type for @Nested test class #4130

Deliverables

• Determine if it is possible to support this use case
• If it is possible, ensure that @DisplayNameGeneration is discovered on the runtime enclosing type for a @Nested test class.

[marcphilipp]

Team decision: Investigate feasibility after #4130 has been addressed.

[abdelmawla56]

hello @sbrannen, I would love to work on this issue, would you please assign it to me?
it will be solved by adding somethings

[marcphilipp]

@abdelmawla56 I'd be happy to but #4130 should be done first because we think there'll be a large overlap. That's why this issue is currently labeled as "blocked".

[snicoll]

This change is leading to deprecation warnings when upgrading as we're relying on SearchOption.

Looking at ed68831, it looks like it has been introduced for a very specific feature, which came a bit as a surprise to me. Our use case is to find an annotation that can be specified on a @Nested-annotated type as well as enclosing types.

Given that @Nested is a feature of JUnit, I was expecting some sort of support which is exactly what the (now deprecated) feature did. Have I missed something or do we have to compute the list of types ourselves now? It also feel the reason for the deprecation is quite subtle (the distinction between the compile-time enclosing types and the runtime enclosing types).

[sbrannen]

Thanks for bringing this up, @snicoll.

We'll discuss this within the team.

[sbrannen]

I searched the Spring Boot code base and discovered the recently introduced ResourcesExtension which uses SearchOption.

@snicoll, can you please confirm that's the use case you are talking about?

Thanks

[wilkinsona]

Yes, that's where we noticed the deprecation.

I would have liked to use the search capabilities here as well but, IIRC, couldn't do so as we're looking for a repeatable annotation there.

We've struggled with supporting the semantics of @Nested in the past. In this case it's not as important as the code in question is an internal test utility so it only needs to work for our own purposes. More generally, I'd definitely welcome anything that eases supporting @Nested and the now-deprecated search capabilities were a step in that direction.

[marcphilipp]

Team decision: Introduce ExtensionContext.getEnclosingTestClasses() : List<Class<?>> method for use with AnnotationSupport.findAnnotation(Class, Class, List<Class>) in 5.12.1

• Introduce ExtensionContext.getEnclosingTestClasses() for use with AnnotationSupport #4375

[wilkinsona]

Thank you!