pytest-cdist
Like pytest-xdist, but for distributed environments - pytest-cdist allows to split a test suite into multiple parts and run them independently.
This is a work in progress
Why?
pytest-xdist can help to parallelize test execution, as long as you can scale horizontally. In many environments, such as GitHub actions with GitHub runners, this is only possible to a fairly limited degree, which can be an issue if your test suite grows large. pytest-cdist can help with this by allowing to execute individual chunks of your test suite in a deterministic order, so you can use multiple concurrent jobs to run each individual chunk.
How?
pytest --cdist-group=1/2 # will run the first half of the test suite
pytest --cdist-group=2/2 # will run the second half of the test suite
In a GitHub workflow
jobs:
test:
runs-on: ubuntu-latest
matrix:
strategy:
cdist-groups: [1, 2, 3, 4]
steps:
- uses: actions/checkout@v4
# set up environment here
- name: Run pytest
run: pytest --cdist-group=${{ matrix.cdist-group }}/4
Usage
Configuration
Pytest-cdist comes with several CLI and pytest-ini options:
| CLI | Ini | Allowed values | Default |
|---|---|---|---|
--cdist-justify-items |
cdist-justify-items |
none, file, scope |
none |
--cdist-group-steal |
--cdist-group-steal |
<target group>:<percentage> / <target group>:<percentage>:<source group> |
- |
--cdist-report |
- | - | false |
--cdist-report-dir |
cdist-report-dir |
. |
Controlling how items are split up
By default, pytest-cdist will split up the items into groups as evenly as possible. Sometimes this may not be desired, for example if there's some costly fixtures requested by multiple tests, which should ideally only run once.
To solve this, the cdist-justify-items option can be used to configure how items are
split up. It can take two possible values:
file: Ensure all items inside a file end up in the same groupscope: Ensure all items in the same pytest scope end up in the same group
[pytest]
cdist-justify-items=file
pytest --cdist-group=1/2 --cdist-justify-items=file
Skewing the group sizes
Normally, items are distributed evenly among groups, which is a good default, but there may be cases where this will result in an uneven execution time, if one group contains a number of slower tests than the other ones.
To work around this, the cdist-group-steal option can be used. It allows to specific
a certain percentage of items a group will "steal" from other groups. For example
--cdist-group-steal=2:30 will cause group 2 to steal 30% of items from all other
groups.
[pytest]
cdist-group-steal=2:30
pytest --cdist-group=1/2 --cdist-group-steal=2:30
It is also possible to redistribute items between two specific groups, by specifying both as source and a target group. The following configuration would assign 50% of the items in group 1 to group 2:
pytest --cdist-group=1/3 --cdist-group-steal=1:50:2
With pytest-xdist
When running under pytest-xdist, pytest-cdist will honour tests marked with
xdist_group, and group them together in the same cdist group.
With pytest-randomly
To use pytest-cdist with pytest-randomly's test reordering, a randomness seed that's consistent across the different pytest invocations needs to be specified, otherwise, test cases would be dropped, since pytest-cdist has to rely on a consistent collection order to split test cases among its groups.
To achieve this, a random source such as the current timestamp can be used:
jobs:
setup_randomly_seed:
runs-on: ubuntu-latest
outputs:
randomly_seed: ${{ steps.set-seed.outputs.randomly_seed }}
steps:
- name: Set seed
id: set-seed
run: echo "randomly_seed=$(date +%s)" >> $GITHUB_OUTPUT
test:
runs-on: ubuntu-latest
needs: setup_randomly_seed
matrix:
strategy:
cdist-groups: [1, 2, 3, 4]
steps:
- uses: actions/checkout@v4
- name: Run pytest
run: >
pytest
--cdist-group=${{ matrix.cdist-group }}/4
--randomly-seed=${{ needs.setup_randomly_seeds.outputs.randomly_seed }}
or a bit simpler (but less random), using the current git hash:
jobs:
test:
runs-on: ubuntu-latest
needs: setup_randomly_seed
matrix:
strategy:
cdist-groups: [1, 2, 3, 4]
steps:
- uses: actions/checkout@v4
- name: Run pytest
run: >
pytest
--cdist-group=${{ matrix.cdist-group }}/4
--randomly-seed=$((16#$(git rev-parse HEAD)))
Metadata
Release files for pytest-cdist 0.5.2
For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.
Source distribution (sdist)
| File | Size | Uploaded | |
|---|---|---|---|
| pytest_cdist-0.5.2.tar.gz | 31.0 kB | Details |
Built distribution (wheel)
| File | Interpreter | ABI | Platform | Reset |
|---|---|---|---|---|
| pytest_cdist-0.5.2-py3-none-any.whl | Python 3 | none | any | Details |
Total release size: 39.3 kB
Release files / pytest_cdist-0.5.2.tar.gz
| Download URL | pytest_cdist-0.5.2.tar.gz |
|---|---|
| Size | 31.0 kB |
| Tags | Source |
|
SHA-256 checksum How to use checksums |
4fca0c79d73869ba8293121786782f615bfb3e8ffe175428a716d193ef1ec484
|
|
BLAKE2b-256 checksum How to use checksums |
55b9bfbfe094302bfabd89a6879cda6c6d9b98b64cd2a9cc55e72b0b6203443d
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
Yes |
| Uploaded via |
twine/6.1.0 CPython/3.13.12
|
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on Jul 7, 2026.
Transparency logRelease files / pytest_cdist-0.5.2-py3-none-any.whl
| Download URL | pytest_cdist-0.5.2-py3-none-any.whl |
|---|---|
| Size | 8.3 kB |
| Tags | Python 3 |
|
SHA-256 checksum How to use checksums |
f41c8b99dab83042473e64d43038c15ea2ea40c4589bae639b29dd92bd468f96
|
|
BLAKE2b-256 checksum How to use checksums |
393a7fdf321ac0828b60d65f3e7b6de5508a7e7425c06cbc0fb6eeb5fc358ce9
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
Yes |
| Uploaded via |
twine/6.1.0 CPython/3.13.12
|
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on Jul 7, 2026.
Transparency log