JUnit Maven integration allows the test classes to be executed in parallel, for that the fork options should be configured.

In our case it would be very beneficial - we could use some good hardware and run the UI tests on several forked JVMs reducing the execution time dramatically. However, the problem is that if we use a single Mgnl author-public pair, the level of entropy is way too high - the test classes may easily step onto each others toes.

To overcome this problem, we should have several Mgnl deployments that are connected to the JUnit forked JVM one-to-one. This way we would maintain the current stability.

The tests however, would need to know, which server they should deal with. There's a couple of ways how that can be achieved:
1) surefire.forkNumber property is available during the test execution and contains the index of the JVM. We could construct the server URL out of that (i.e. the test would connect to *http://server-1:8080* or *http://server-2:8080* and so on). This is an easy to implement option, but it would require us to manage the mgnl deployments ourselves, i.e. we won't be able to just tell Docker to deploy 5 Mgnl instances on three different machines and run tests with them.

2) We could run the instances as a Swarm service, which makes it harder to address an instance individually (because they will be behind Swarm load balancer), but it would be possible to provide a custom load balancing strategy to the swarm, which will implement the hard link between the IP used by a forked JVM and the Mgnl instance (check out related HAProxy article and Docker tutorial ). This way the Mgnl deployment access would be transparent to the tests completely. Drawback - we'd need to fiddle a bit with load balancers and proxies (each forked JVM would probably need another personal HAProxy instance to mimic the unique IP address).