Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Appearance settings
Discussion options

I am implementing improved leak detection for the netty project test suite. For this purpose, it is necessary to clearly determine which test class (and associated resource scope) a resource is allocated in. At the end of the test class (AfterAll), a junit5 extension will verify that all resources allocated in the class have been released.

To implement this, I use an InheritableThreadLocal created in BeforeAll. However, I had some issues with this approach when running tests concurrently. JUnit uses a ForkJoinPool which may lead to test methods running on different threads, or methods from other test classes running on the thread a particular class was started on.

As a temporary solution, I assign the thread local in BeforeAll and in BeforeEach, with proper handling for nesting. You can look at the implementation in this PR. But this seems like a hack. If a test were to run a ForkJoinTask itself for example, this would not be enough.

Is there a better solution to this, or is a better solution planned? Running tests using virtual threads could help for example, and there is an issue (#3442) for this. A more compatible solution would be to use a non-ForkJoin thread pool for test execution, but I'm not sure this is desirable.

You must be logged in to vote

I think there's no way around assigning the ThreadLocal on the thread that will invoke the test. I think it might be easier to implement InvocationInterceptor, though, because that would avoid having to do the nesting with the help of the ExtensionContext.Store. Instead, a try-finally block could be used to set and then reset the ThreadLocal. Moreover, this could be extended to not just support interceptTestMethod, but also all kind of lifecycle methods, etc.

Replies: 1 comment · 3 replies

Comment options

I think there's no way around assigning the ThreadLocal on the thread that will invoke the test. I think it might be easier to implement InvocationInterceptor, though, because that would avoid having to do the nesting with the help of the ExtensionContext.Store. Instead, a try-finally block could be used to set and then reset the ThreadLocal. Moreover, this could be extended to not just support interceptTestMethod, but also all kind of lifecycle methods, etc.

You must be logged in to vote
3 replies
@yawkat
Comment options

Thanks for the InvocationInterceptor suggestion. I did not know about it, and it feels much less hacky than using BeforeEach.

Now the only thing to worry about is nested fork join tasks (e.g. parallel streams), but that's controllable for now. I'll just wait for virtual thread support.

@yawkat
Comment options

Actually, it looks like it's not enough, because @ParameterizedTest parameter discovery cannot be intercepted 😞 I guess I'll have to stick with the BeforeAll hack.

@marcphilipp
Comment options

Sounds like you'd want #2579 in order to intercept those, too.

Answer selected by yawkat
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Category
🙏
Q&A
Labels
None yet
2 participants
Morty Proxy This is a proxified and sanitized view of the page, visit original site.