Skip to content

Support declarative extension registration on fields and parameters #864

@nipafx

Description

@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

Metadata

Metadata

Assignees

Type

No type

Projects

No projects

Milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions