You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I am currently writing a small extension which implements ParameterResolver to provide a few parameters which need to be shut down after the test. After reading the documentation, my first intuition was to write the extension like this:
The problem with that solution is that the ExtensionContext is scoped for the whole test class when resolving arguments for the test class constructor, although the test uses TestInstance.Lifecycle.PER_METHOD. As a consequence, my example above will use the same parameter for all tests, instead of creating a new one per test. The documentation does not describe a lot of details about the lifecycle of each ExtensionContext, therefore I cannot declare it as a bug, but this behavior is very unexpected in my opinion. Since the callbacks are on the level of the individual tests, I expected the ExtensionContext to be scoped to the test as well. The same problem applies to TestInstancePreConstructCallback. I haven't tested TestInstanceFactory, but I guess it is also affected.
The obvious workaround is to also add a TestInstancePreDestroyCallback which closes the parameter and removes it from the store. Note that the implementation of that method is not trivial because in contrast to the methods above, this callback receives a child store which is scoped to the test. Unfortunately, this means that calling remove on the given store directly instead of iterating over the parents would not work.
@OverridepublicvoidpreDestroyTestInstance(ExtensionContextcontext) {
ParameterWrapperwrapper = null;
do {
wrapper = context.getStore(NAMESPACE).remove(ParameterWrapper.class, ParameterWrapper.class);
context = context.getParent().orElse(null);
} while (context != null && wrapper == null);
if (wrapper != null) wrapper.close();
}
Deliverables
Test-scoped ExtensionContext for TestInstancePreConstructCallback
Test-scoped ExtensionContext for test specific callbacks in ParameterResolver
Test-scoped ExtensionContext for TestInstanceFactory
We agree that this is a valid use case that should be simpler to accomplish. We'd like to investigate whether it's feasible to inject the method-level ExtensionContext if Lifecycle.PER_METHOD is used and, if so, for which extension interfaces.
TestInstancePreConstructCallback and TestInstancePreDestroyCallback are not symmetric, the context of the latter is the child of the former. Therefore, removecalls from the latter fails, the store is in the parent. TestInstancePreConstructCallback recives a context that outlives the test using the default config when the extenxion is configured in the test class.
In my opinion, ParameterResolver and TestInstancePreConstructCallback should receive a context just for the current test if the life cycle is configured per method.
I am currently writing a small extension which implements
ParameterResolver
to provide a few parameters which need to be shut down after the test. After reading the documentation, my first intuition was to write the extension like this:The problem with that solution is that the
ExtensionContext
is scoped for the whole test class when resolving arguments for the test class constructor, although the test usesTestInstance.Lifecycle.PER_METHOD
. As a consequence, my example above will use the same parameter for all tests, instead of creating a new one per test. The documentation does not describe a lot of details about the lifecycle of eachExtensionContext
, therefore I cannot declare it as a bug, but this behavior is very unexpected in my opinion. Since the callbacks are on the level of the individual tests, I expected theExtensionContext
to be scoped to the test as well. The same problem applies toTestInstancePreConstructCallback
. I haven't testedTestInstanceFactory
, but I guess it is also affected.The obvious workaround is to also add a
TestInstancePreDestroyCallback
which closes the parameter and removes it from the store. Note that the implementation of that method is not trivial because in contrast to the methods above, this callback receives a child store which is scoped to the test. Unfortunately, this means that calling remove on the given store directly instead of iterating over the parents would not work.Deliverables
ExtensionContext
forTestInstancePreConstructCallback
ExtensionContext
for test specific callbacks inParameterResolver
ExtensionContext
forTestInstanceFactory
-- or --
Related issues
ParameterResolver
of@MethodSource
factory method #3323The text was updated successfully, but these errors were encountered: