The thread context classloader is not reset between tests

[gregw]

version junit 5.8.2

Steps to reproduce

If a test that passes leaves the thread context classloader set, it may break a subsequent test, which itself passes if run by itself. For example:

public class ContextClassLoaderTest
{
    static final ClassLoader LingeringLoader = new URLClassLoader(new URL[0], Thread.currentThread().getContextClassLoader());

    @Test
    public void testA()
    {
        assertThat(Thread.currentThread().getContextClassLoader(), not(sameInstance(LingeringLoader)));
        Thread.currentThread().setContextClassLoader(LingeringLoader);
    }

    @Test void testB()
    {
        assertThat(Thread.currentThread().getContextClassLoader(), not(sameInstance(LingeringLoader)));
        Thread.currentThread().setContextClassLoader(LingeringLoader);
    }
}

Both testA and testB pass if run by themselves, but if run together, then the second always fails.

I tried a similar test with the thread interrupted status and noted that we reset between test runs, so I think the thread context loader should also be reset.

Context

Failures seen in:
-- maven command line
-- Intellij IDE

[sormuras]

Thanks for raising this issue, Greg.

I can't find a related issue, but if I remember correctly, we discussed whether or not to (re-)set the TCCL before each test execution at some point in the past. We ended up in not doing so, in order support use-cases that set a TCCL spanning multiple test calls. @marcphilipp and @sbrannen ... can you remember better than me?

What about guarding your TCCL-aware tests? For example with a test-internal try-finally construct or via a resetting life-cycle method annotated with @BeforeEach or @AfterEach?

[sbrannen]

I tried a similar test with the thread interrupted status and noted that we reset between test runs,

That was addressed in #1688.

I can't find a related issue, but if I remember correctly, we discussed whether or not to (re-)set the TCCL before each test execution at some point in the past. We ended up in not doing so, in order support use-cases that set a TCCL spanning multiple test calls. @marcphilipp and @sbrannen ... can you remember better than me?

I honestly don't recall exactly. We may have discussed that and came to that conclusion, but I cannot find a related issue either.

These are the major open issues regarding class loaders:

• Introduce extension API for providing a custom ClassLoader (e.g., for Powermock) #201
• Revise ClassLoader lookups across the platform #806

[sbrannen]

Actually, I found the other issue:

• Thread context classloader should be reset after each test #1799

I'm therefore closing this issue as a duplicate.