Test runs should be as fast as possible in order to allow a lean development cycle. One of the applications is a Continuous Deployment (see Lean Startup).
Using strong multi-core machines to run tests is not enough since most unit tests are using a single thread per test. Apart of reducing IO to minimum, having tests running in parallel is required to squeeze the juice of of the machine. Additional value from Parallelizing JUnit test runs is ensuring that tests have no dependency between each other.
The way we implemented parallel test runs is creating an ANT target with a parallel task containing N JUnit tasks where N == number of cores. For example:
<parallel> <junit printsummary="yes" haltonfailure="yes" fork="true" maxmemory="${maxmemory}" showoutput="yes"> <jvmarg value="-XX:MaxPermSize=${permMem}"/> <jvmarg value="-Xms${minMem}"/> <jvmarg value="-Xmx${maxmemory}"/> <classpath refid="classpath.test" /> <formatter type="xml" usefile="true" /> <test name="com.kaching.GroupedTests$GroupA" todir="${testTargetJunit}" unless="testcase"/> </junit> <junit printsummary="yes" haltonfailure="yes" fork="true" maxmemory="${maxmemory}" showoutput="yes"> <jvmarg value="-XX:MaxPermSize=${permMem}"/> <jvmarg value="-Xms${minMem}"/> <jvmarg value="-Xmx${maxmemory}"/> <classpath refid="classpath.test" /> <formatter type="xml" usefile="true" /> <test name="com.kaching.GroupedTests$GroupB" todir="${testTargetJunit}" unless="testcase"/> </junit> ... </parallel>
The GroupedTests$GroupX are classes extending TestCase with a public static Test suite(). The suite() method creates a JUnit test suite on the fly by loading all the tests in scope and filtering them out. If for example there are four cores, therefore you would like to have a group of four suites each running fourth of the tests. The suits are using a java.util.Random seeded with the commit revision number. Using the Random object we decide on placing test cases in suits.
random.nextInt(numOfTestSuites) == testSuiteId
Therefore a testcase goes to a single suite and they are evenly distributed between suites. Randomness in assigning test cases to suites (and therefore to processes) gives us some reassurance that there are no dependencies between tests.
As a result we have the tests running about twice as fast as they did before, in the range of 2 min, 20 sec for about 4.6k tests for one of our components, including code fetch from source repository, clean, build, and test suite setup time. It gives us a nice 100% test machine utilization and faster commit to production deployment cycle (about four minutes).