-
Notifications
You must be signed in to change notification settings - Fork 0
Parallel Execution
As of the time of this writing, parallel execution of scenarios/features is not yet officially supported in the official behave release. However, there have been a number of forks (one of which has an unfulfilled PR into behave) that offer parallel execution support, to varying degrees of success.
Given that none of these forks have been merged in nor do they have an official pip release, installing and using these forks to achieve parallel execution is a bit more involved. There are probably better ways to go about this (i.e. writing a batch script to clone and pack the forked repo into a local wheel package that is installed as a separate package directly into the virtualenv) but for now these are the steps to get going quickly:
$ cd web-bdd
$ git clone -b eparallel https://github.com/xrg/behave-parallel.git
$ pipenv --venv
Take note of the resulting directory path from the last command. Navigate to that directory and from there go into /Lib/site-packages/ where you should find your existing behave installation directory. Make a backup of the behave directory here.
Now go back into the /web-bdd/behave-parallel/ directory that you cloned, find the modified behave directory, and copy it over to your virtualenv directory, replacing the default behave directory.
Now, when you run behave from your virtualenv, you will be executing the behave-parallel version, and you can specify additional params like so:
$ pipenv run behave --processes 4 --parallel-element feature -D headless=true
behave-parallel is not entirely bug free so that's why I recommend keeping a backup of the official behave branch. (And also why I would like to modify this whole process with a script that can install behave-parallel as a separate virtualenv package instead of overwriting existing packages.)
For instance, when running tests in parallel, even though all functionality will execute as you'd expect, the final output summary may falsely mark your steps/scenarios/features as untested rather than the expected passed or failed. For this reason, I don't recommend relying on the standard behave test results output for this and instead recommend using a custom logging / test results reporting mechanism when running tests in parallel.