-
-
Notifications
You must be signed in to change notification settings - Fork 1.6k
Description
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.