Exposing a pooled object via a ParameterResolver?

[roded]

Hello,
I have a pool of resources which I'd like to share between all test classes and methods (running in parallel).

I've considered creating an Extension which:

1. Allocates the pool and adds it to the ROOT namespace's Store. The pool object will implement ExtensionContext.Store.CloseableResource so once the ROOT namespace Store is closed, it will be closed as well.
2. Implements the ParameterResolver interface which allows tests to request a pooled instance. So when ParameterResolver.resolveParameter is called, an object will be borrowed from the pool and injected.

But what I have not solved yet is how to handle returning borrowed objects to the pool once their context is complete.
The borrowed objects can themselves implement ExtensionContext.Store.CloseableResource which could handle returning the object to the pool but:

1. When injecting a borrowed object into a beforeAll method, the context seems to span the execution of all test methods in the class. This makes sense, but is unfortunate for my purpose since an object will be held for the entire class's duration.
2. Similarly, when injecting a borrowed object into a test class's ctor, it's unclear to me what ExtensionContext will be used.

Is there a better way to accomplish this?

Thanks

[marcphilipp]

1. When injecting a borrowed object into a `beforeAll` method, the context seems to span the execution of all test methods in the class. This makes sense, but is unfortunate for my purpose since an object will be held for the entire class's duration.

2. Similarly, when injecting a borrowed object into a test class's ctor, it's unclear to me what `ExtensionContext` will be used.

In both cases the class-level context will be used. Have you considered using a @BeforeEach method instead?

[roded]

Oh, I was under the impression that JUnit would create the test class again before every test method.
I can use @BeforeEach and @AfterEach to borrow and return objects from the pool for every test. It is very verbose though (and prevents the use of final fields). I thought I could accomplish a more elegant solution in which resources are borrowed from the pool, injected and then returned to the pool by the extension and without the test class handling any of that.

I'm fine with cutting my loss though.

Thanks for the reply.

[marcphilipp]

It depends on the configured @TestInstance lifecycle. With PER_CLASS there will be a single test instance, with PER_METHOD (the default) one per test method.