Stages/Concepts
Test Class Scanning
The first stage of test execution is detecting which classes are tests and need to be executed. For this we use the current test class scanner. This is done in a separate thread and test classes are queued on a blocking queue.
Test Execution Pipeline Splitting
We have a stage to split the tests over multiple 'test execution pipelines'. This stage determines on which pipeline a test should be executed and queues it on the test class queue of the pipeline. This is can map one on one with test forks but it doesn't have to be.
Test Server
Each test execution pipeline has a test server that feeds tests to test fork(s). A single test server can feed tests to more than one test fork. Because of this there is no implied mapping between execution pipelines and test forks.
Test Forks
Each test fork is connected to only one test server that provides the fork with work ( tests to execute / wait / exit/ ... ). A reference the to the process is kept with an ExecHandle.
A shared classloader contains the test framework (junit/testng) jar file(s) both the control and sandbox classloader have the shared as parent. The control classloader contains Gradle control classes to execute the tests and communicate with the test server. The sandbox classloader contains the class and test class directories + everythin in the testRuntime configuration except the test framework jar(s).
The classes/jars that need to be on each classloader are specified in a property file that is passed to the forklaunchmain class. The property file also contains the startup parameters of the fork controller class that is instanciated in the control classloader. Once the fork controller is instanciated execution control is passed to it. It also receives all the setup classloaders so it can use them if needed. For test execution only the sandbox classloader is needed to instanciate the test classes, but we may use the forklaunchmain for other purposes aswell.
more information is coming...