Example of running JUnit tests as parameterized AND parallel at the same time


(Jon Austen) #1

I created a simple example of running JUnit tests as parameterized AND parallel at the same time.

This would have been VERY helpful to me in the past and so I am sharing this to help out others.

With this method, of course, there is no need to fork processes with Gradle since JUnit will do it.

It works great, as far as multi-threading goes, creating a thread pool for each class and multiple threads per pool, but the Gradle report lacks some detail when providing report information: the Gradle report displays zero information about the class files involved in the test suite and zero info about the threads in the suite (aside from the debug log).

https://gist.github.com/djangofan/5006098


(Peter Niederwieser) #2

What are you trying to accomplish with this, instead of using Gradle’s parallel test execution? As far as I know, ParallelRunner has never left experimental stage, and no released version of JUnit is thread-safe. Besides, ‘JUnitCore’ and ‘ParallelComputer’ are only meant to be used by the party that’s in control of test execution (build tool, IDE). If you use it from a test, you essentially kick off your own inner test execution, and there is no way for the outer party to know about that. That’s why you don’t see anything in the Gradle report.


(Jon Austen) #3

Finding information or examples of running a parallel test suite using Gradle was hard enough for me to find that I never found it.

This is the closest that I have come to actually being able to run parallel tests using JUnit.

I would MUCH prefer a Gradle alternative but I couldn’t locate the info.

Can you point me in the right direction?


(Peter Niederwieser) #4

http://www.gradle.org/docs/current/userguide/java_plugin.html#sec:java_test

http://www.gradle.org/docs/current/dsl/org.gradle.api.tasks.testing.Test.html#org.gradle.api.tasks.testing.Test:maxParallelForks

tasks.withType(Test) {
    // experiment with different values to see what works best
    maxParallelForks = 4
     // can also compute dynamically
    // maxParallelForks = Runtime.runtime.availableProcessors() / 2
}

(Jon Austen) #5

Ok, I didn’t realize that setting greater than 1 actually triggers forking.

The doc doesn’t actually say that but it makes perfect sense now.

I tried it and the reports look at lot better. During the run the individual threads don’t identify themselves in the log (at the INFO level) and I was wondering if you know of a way that I can get them to do that?


(Peter Niederwieser) #6

Test execution always forks at least one JVM. That’s why it’s called ‘maxParallelForks’. Each test JVM runs a single test thread. Usually it doesn’t help to know in which JVM a test is running, but if you want to know, you can do something like ‘test.testLogging.events “started”, “passed”, “failed”, “skipped”; test.testLogging.displayGranularity = 0’. As always, see the DSL reference for details.


(Jon Austen) #7

I finally got this all working, executing parallel with Gradle. Here is my test that shows how to do it: https://github.com/djangofan/junit-suite-order


(Sebastian Harko) #8

Hi , the link to the github gist is no longer working. Does anyone have such an example ? It would be very useful. Cheers !


(Sebastian Harko) #9

Hi , the link to the github gist is no longer working. Does anyone have such an example ? It would be very useful. Cheers !


(Sebastian H) #10

Does anyone have such an example ?

Jon Austen’s link is unfortunately broken ;

Thanks.


(Jon Austen) #11

Sorry about the broken link: https://github.com/djangofan/junit-suite-order

. Keep in mind that I do not suggest using JUnit to fork tasks. The Gradle runner is a better way to fork test processes.

This was all a learning experience for me.

The above project is a good project to run just to show the difference though.