In JUnit it could be occasionally helpful to run a test in its own thread. In particular when writing integration tests that interact with encapsulated ThreadLocal s or the like this could come in handy. A separate thread would implicitly ensure that the thread related reference of the threadlocal is uninitialized for each test run. This post introduces a JUnit Rule that provides such a functionality and explains how to use it.

Testing with JUnit Testing with JUnit is one of the most valuable skills a Java developer can learn. No matter what your specific background, whether you’re simply interested in building up a safety net to reduce regressions of your desktop application or in improving your server-side reliability based on robust and reusable components, unit testing is the way to go. Frank has written a book that gives a profound entry point in the essentials of testing with JUnit and prepares you for test-related daily work challenges. Get It Now!

To begin with take a look at the following example. It depicts a test case that produces intermittent failures of testB . The reason for this is that the outcome depends on the execution order of all tests due to side effects . More precisely Display.getDefault() in principle returns a lazily instantiated singleton, while Display.getCurrent() is a simple accessor of this singleton. As a consequence testB fails if it runs after testA .

public class FooTest { @Test public void testA() { Display actual = Display.getDefault(); assertThat( actual ).isNotNull(); } @Test public void testB() { Display actual = Display.getCurrent(); assertThat( actual ).isNull(); } }

To avoid some behind-the-scene-magic, which bears the risk to make code less understandable, we could ensure that an existing display is disposed before the actual test execution takes place .

@Before public void setUp() { if( Display.getCurrent() != null ) { Display.getCurrent().dispose(); } }

Unfortunately this approach cannot be used within an integration test suite that runs PDE tests for example. The PDE runtime creates a single Display instance, whose lifetime spans all test runs. So display disposal would not be an option and testB would fail within PDE test suite execution all the time .

At this point it is important to remember that the Display singleton is bound to its creation thread (quasi ThreadLocal ) . Because of this testB should run reliable, if executed in its own thread.

However thread handling is usually somewhat cumbersome at best and creates a lot of clutter, reducing the readability of test methods. This gave me the idea to create a TestRule implementation that encapsulates the thread handling and keeps the test code clean:

public class FooTest { @Rule public RunInThreadRule runInThread = new RunInThreadRule(); @Test public void testA() { Display actual = Display.getDefault(); assertThat( actual ).isNotNull(); } @Test @RunInThread public void testB() { Display actual = Display.getCurrent(); assertThat( actual ).isNull(); } }

The RunInThreadRule class allows to run a single test method in its own thread. It takes care of the demon thread creation, test execution, awaiting of thread termination and forwarding of the test outcome to the main thread. To mark a test to be run in a separate thread the test method has to be annotated with @RunInThread as shown above.

With this in place testB is now independent from the execution order of the tests and succeeds reliable. But one should be careful not to overuse RunInThreadRule . Although the @RunInThread annotation signals that a test runs in a separate thread it does not explain why. This may easily obfuscate the real scope of such a test. Hence I use this usually only as a last resort solution. E.g. it may be reasonable in case when a third party library relies on an encapsulated ThreadLocal that cannot be cleared or reset by API functionality.

For those who like to check out the RunInThreadRule implementation I have created a GitHub gist:

https://gist.github.com/fappel/65982e5ea7a6b2fde5a3

For a real-world usage you might also have a look at the PgmResourceBundlePDETest implementation of our Gonsole project hosted at

https://github.com/rherrmann/gonsole.