How to run tests, but not suites in parrallel


We have a Robot Framework test set with a lot of files (suites). Each of the files has its own ‘Suite setup’ in which it assures that the required data for the tests in the suite is available. The ‘Suite setup’ of one suite undo’s the ‘Suite Setup’ of another. None of the tests in a suite depend on other tests in the same suite nor on any other tests in other suites.

I would like to run all suites sequentially, but all tests in one file (suite) in parallel. Using the ‘–testlevelsplit’ argument I haven’t been able to prevent the suites to be running in parallel too.

Is this scenario even possible with the curring version of Pabot?

Thanks in advance!


FYI. I’ve already seen that I can assure that the setup will only be executed once using Pabot library.

Hi Björn,

I don’t really use pabot myself though i’ve had a brief play with it years ago.

Idea 1:
Checking the doco, there seems to be a section on Controlling execution order and level of parallelism, using an ordering file, though my guess is that if you had 2+ parallel robots and an odd number of tests in one suite there will be some overlap where tests from 2 suites will be executing at the same time (though hopefully in different processes) so this may be all you need?

Though this bit looks helpful:

You can add a line with text #WAIT to force executor to wait until all previous suites have been executed

Idea 2:
Another way of dealing with this which will definitely resolve the issue, would be take a step back from pabot and control it at the os level, use a shell/batch script to loop over the suite files with a for loop, then you call pabot with one suite_file.robot at a time, then pabot will finish the suite and exit before returning to the os shell script which then calls pabot with the next suite file.

Hope this helps,


Hi Dave,

Thanks for your suggestions. I was hoping that I missed an option in the docs of Pabot, but unfortunately I didn’t.

I’ll first try to set up a PoC to verify if we will benefit from running tests in parallel. And if we do we will perform some analysis on our best options.