Support declarative extension registration on fields and parameters

[nipafx]

Overview

Original title: "Support ParameterResolver registration via @ResolveWith on parameter"

While experimenting with parameter resolvers I realized that they can not be applied like argument converters can, i.e. by annotating the parameter directly. This complicates their application and implementation if they are "annotation based".

An example is the @Mock proof of concept. The resolver has to be applied to the test method or class and because of that has to check the individual parameter for the presence of the @Mock annotation. This indirection causes unnecessary complexity for implementers and users of the extension.

Original Proposal

I propose an annotation similar to @ConvertWith, e.g. @ResolveWith, that takes precedence over all registered parameter resolvers. It does not need a supports method because it is assumed to support the parameters it is applied to. If it turns out during resolve that that's not the case, the test should be aborted by an exception.

With this mechanism, @Mock (and I am planning to write something like @Random) would get simpler to use because they only need to be applied in one place.

More broadly, I think parameter resolvers and argument converters are conceptually very similar and the API would hence improve considerably if both would operate similarly as well. In that regard I already opened #853, which proposes an extension point to register converters at the method and class level. Together with this issue, the two aim to align both mechanisms.

If there is interest in this, I would give it a shot, preferably together with #853.

Related Issues

• Support @ExtendWith on fields #416
• Support programmatic extension registration via fields #497

[sormuras]

Like?

class SudokuTests {
  @RepeatedTest(10)
  void testSomeGeneratedSudokus(@Random int seed) {
    assertTrue(Sudoku.generate(seed).isSolvable());
  }
}

Edit: now with simple class body w/o any parameter resolver on the class level.

[nipafx]

Yes. But without registering any parameter resolver on the class level and without the chance of @Random conflicting with them.

[sbrannen]

Related discussion on Twitter about being able to register extensions on parameters:

https://twitter.com/olivergierke/status/1022802925603758080

[sbrannen]

Renamed issue to align with the title of #497 and features discussed in the aforementioned Twitter thread.

[sbrannen]

Updated scope to include registration via fields and parameters.

[sbrannen]

Current work on this issue can be viewed in the following branch:

https://github.com/junit-team/junit5/compare/issues/864-declarative-extension-registration-params-fields

[sbrannen]

in progress