Here is what I have done.
I tried to run Groovy Closures in multiple Java Threads (2 threds, 4 threads, 8 threads, …) in a Test Case script. It worked for me.
However I do not recommend you to follow this way. Because any problems in this system are difficult to analyse and fix. I haven’t developed any easy-to-use debugging facility for “multi-threaded Test Cases” (I am not capable of developing such magical thing). I only have the Stack Trace messages emitted by Exceptions. I am OK with it, but you would be not. I do not think I can support you remotely.
I hoped that executing multiple Groovy Closures in parallel will make my Test Case run far faster than running them sequentially. 2 times faster, 4 times faster, 8 times faster.
But our life is not as easy as that.
My research revealed that multi-threaded Test Case did not run faster than the single-threaded process. Even slower sometimes. There were several reasons; ChromeDriver somehow takes longer time to launch browser; running multiple browsers in parallel requires faster network connection to the Internet but my WiFi is too slow; the CPU of my Mac Book Air got too busy; tests failed due to delays caused by various occasional reasons. Still I do not think that multi-threading caused slowness. I learned a simple & fundamental lesson: I need more machine + network resources to process more tasks in a limited time frame.
Plus I need to write my tests very robust. Otherwise, a multi-threaded test becomes a chaos.
in order to make your test run faster, it would be easier and safer for you to allocate more machine resources . You should distribute the jobs to multiple machines. This is where Cloud computing environment (AWS, GCP) shines. If you want your test run 10 times faster, then you should distribute the job onto 10 instances of AWS lambda with 10 licenses of KRE, perhaps.