Thread context classloader should be reset after each test

[bacer-esteco]

Overview

Whenever a test case sets the thread context ClassLoader, the test runner thread keeps using that ClassLoader for the following tests. This causes failures when combined with Mockito and mocks of package private classes/interfaces.

Expected Behavior

When the thread is reused to run another test, the context ClassLoader should be reset to the original one.

Steps to Reproduce

To reproduce the problem I created this example repo: https://github.com/bacer-esteco/junit5-bug-report.

Just run the 'test' task.

This problem is reproducible using both Jupiter and Vintage (tried on version 5.4.0), launching the test both from Gradle 5.2.1 and IntelliJ IDEA 2018.3 (and previous).

Related Issues

• Introduce extension API for providing a custom ClassLoader (e.g., for Powermock) #201
• Interrupted test cases cause random failures with thread reuse #1688

[sormuras]

Whenever a test case sets the thread context classloader...

...then test case is in charge to teardown the setup it needed to execute.

[sbrannen]

Whenever a test case sets the thread context classloader...

...then test case is in charge to teardown the setup it needed to execute.

I certainly agree that tests should clean up whatever they set up, but I can also understand the desire to have the framework ensure that rogue code doesn't mess up the thread context ClassLoader for the rest of the test plan.

[sbrannen]

Tentatively slated for 5.5 M1 for team discussion

[sbrannen]

I can also understand the desire to have the framework ensure that rogue code doesn't mess up the thread context ClassLoader for the rest of the test plan.

In that regard, this issue is related to #1688.

[sormuras]

What about System.out, System.err, System.properties(), and other "well-known" global resources? Reset them too?

[sbrannen]

What about System.out, System.err, System.properties(), and other "well-known" global resources? Reset them too?

As a framework, we certainly have to draw the line somewhere, but let's not forget that we'll have to set/reset the thread context ClassLoader in conjunction with #201 anyway.

So maybe we should close this issue in favor of a subtask for #201.

[sormuras]

Couldn't resist ... @NewVirtualMachine(Lifecycle.PER_METHOD)