Java/Maven, Programming

Testing threads with JUnit

Sometimes there is a need to test a simple piece of multi-threaded code. For example, how will your code behave, when two threads read and then modify one of the variables? Well, if you know your threads you can devise and code the scenario, so that thread access is exactly right. For example, by using a mutex or semaphore. But how do you assert that your test succeeds? I mean besides sitting next to it with a debug session and checking things on every step.

JUnit is a very nice framework, but it does not handle assertions within other threads as well as one would hope it could.

I will use JUnit 4.0, but this applies to earlier versions as well.

In the sample below we have two test cases, testCaseNaive() will try to do the thing that should work out of the box. However, as far as JUnit is concerned the test succeeds with flashing lights and shooting ribbons. The second test case, testCase2Threads(), uses a somewhat hackish trick. And this trick does involve you creating the two runnables right here in the test.

The idea is quite simple, assertions in JUnit propagate up through the stack by throwing an exception, which is then caught by the test runner. If we get to execute the last statement in the thread as planned – all is well, no assertions were violated, if not – something has gone wrong. And in the case of a fail we rely on the test runner to print out the exception.


import java.util.ArrayList;
import java.util.Vector;
import junit.framework.Assert;
import org.junit.Test;

public class TestMyClass {

	@Test public void testCaseNaive() throws InterruptedException{
		Runnable runnable1 = new Runnable() {
			@Override public void run() {;
		Thread t1 = new Thread( runnable1 );
	@Test public void testCase2Threads() throws InterruptedException {
		final ArrayList< Integer > threadsCompleted = new ArrayList< Integer >();
		Runnable runnable1 = new Runnable() {
			@Override public void run() {;
		Runnable runnable2 = new Runnable() {
			@Override public void run() {
				Assert.assertTrue( true );
		Thread t1 = new Thread( runnable1 );
		Thread t2 = new Thread( runnable2 );
		System.out.println( "Threads completed: " + threadsCompleted );
		Assert.assertEquals(2, threadsCompleted.size());
// testCaseNaive() passes, but the output still contains this
Exception in thread "Thread-0" junit.framework.AssertionFailedError: null
	at TestMyClass$
	at Source)
// testCase2Threads() fails and the output is:
Exception in thread "Thread-1" junit.framework.AssertionFailedError: null
	at TestMyClass$
	at Source)
Threads completed: [2]

Generally speaking, I have not found a nice way to assert fine detail inside a thread. The exceptions are cut off from the main thread and therefore never reach the runner. So the only way to look at these tests is to test the side effects after the test is complete or in the middle of the execution, if you can stop your threads reliably.


JUnit Testing Under Maven2

JUnit testing provides an easy to use flexible framework to write unit tests for Java code. Maven incorporates this functionality as part of it’s software life cycle. JUnit plug-in under maven2 is called Surefire.

> mvn test

Putting the above on the command line will compile the test code and run it.This is really convenient when testing someones code or if you are willing to test everything.

Single Test

However if you are the developer and are working on one specific feature tested in one test case you can run:

> mvn -Dtest=MyTestCase test

This will compile all the tests, but will run only the specified one.

Multiple Selected Tests

Sometimes you want to run just a selected set of tests. For example 2 out of 50:

> mvn -Dtest=MyTestCase,MyOtherTestCase test

This will compile all the tests, but will run only the specified two tests.

Wild Cards

You can use ‘*’ in the anywhere in the name of the class. However be careful if you have inner classes as for example My* will match MyTestCase and MyTestCase$1, which is the inner class you have used in the code, but it is not really a test and therefore the build will fail. Link to Documentation .


However what happens if you have discovered a bug or for some other reason edited the functional code (the one you are testing)? You will be surprised, but maven will not pick it up and will continue the old version of the compiled code. To make it compile the entire sub-project you should first clean it.

> mvn clean -Dtest=MyTestCase test

This will clean your target/ directory and therefore get rid of the old compilations. Then it will recompile the whole project along with the testing code, but still run only MyTestCase.

Abstract Tests

Before Maven 2.0.8 test cases starting with a word Abstract were not considered to be real tests. Abstract Tests are usually used if you have some testing code, which is common for 2 test cases. Then you would write an Abstract*Test class and extend it by the 2 test cases. The inheritance allows you to have the code in one place, but Abstract tests are not really test cases, so they should not be run. This changed with the new version. Excludes property contains the patterns of names, which should be excluded from testing. With its help you can remove the Abstract tests again if your project relies on it.In your pom.xml you should add:



      <!-- Added test excludes for Abstract -->

      <!-- ....... other configuration ....... -->