Support non-default constructors for DisplayNameGenerator implementations

[wazzeps]

It would be nice to be able to pass an object to the generator implementation constructor, which can receive test methods names from an external system.

This object could be used in other parts of the project, or even managed by DI framework context. That is why a constructor is preferable to creating it in a generator class.

[sbrannen]

It would be nice to be able to pass an object to the generator implementation constructor, which can receive test methods names from an external system.

Who would pass the object to the generator's constructor?

Why can't you just look up the "test method names" within the default constructor (or some collaborator to which the default constructor delegates)?

This object could be used in other parts of the project, or even managed by DI framework context. That is why a constructor is preferable to creating it in a generator class.

There is no "DI framework" per se in JUnit Jupiter.

Are you perhaps referring to ParameterResolver support?

[wazzeps]

In my case, I use Spring context which manages a bean that provides access to an external system. Let's call it ExternalSystem.

Then I would like to inject it through a constructor into the generator class to get test method names in the overridden generator methods.

private final ExternalSystem externalSystem;

@Autowired
public ExternalSystemDisplayNameGenerator(ExternalSystem externalSystem) {
    this.externalSystem = externalSystem;
}

...

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

[marcphilipp]

Team decision: DisplayNameGenerators are invoked at discovery time, i.e. before the Spring extension is created and has a chance to create an application context that would be a prerequisite for doing DI. Therefore, this isn't possible with the current architecture.