Maximum number of tests scheduled in one step.
Setting it to 1 will force pytest to send tests to workers one by one -
might be useful for a small number of slow tests.
Larger numbers will allow the scheduler to submit consecutive chunks of tests
to workers - allows reusing fixtures.
Unlimited if not set.
Fixes#855Fixes#255
* Restore old initial batch distribution logic in LoadScheduling
pytest orders tests for optimal sequential execution - i. e. avoiding
unnecessary setup and teardown of fixtures. So executing tests in consecutive
chunks is important for optimal performance.
Commit 09d79ace35 optimized test distribution for
the corner case, when the number of tests is less than 2 * number of nodes.
At the same time, it made initial test distribution worse for all other cases.
If some tests use some fixture, and these tests fit into the initial batch,
the fixture will be created min(n_tests, n_workers) times, no matter how many
other tests there are. With the old algorithm (before
09d79ace35), if there are enough tests not using
the fixture, the fixture was created only once.
So restore the old behavior for typical cases where the number of tests is
much greater than the number of workers (or, strictly speaking, when there
are at least 2 tests for every node).
In my test suite, where fixtures create Docker containers, this change reduces
total run time by 10-15%.
This is a partial revert of commit 09d79ace35
Co-authored-by: Bruno Oliveira <nicoddemus@gmail.com>
- Use pytest>=6.2 features (same as install_requires).
When we can require >=7, can fix some more typing omissions and
version checks.
- Replace testdir with pytester
- Replace py.test with pytest
- Replace tmpdir with tmp_path
- Remove (almost) all other uses of py
- Add some type annotations (not checked yet)
Ref #722.
number of nodes is more than half the number of tests. This makes it
possible, for example, to run all tests in parallel, where previous
the maximum parallelization was half of all tests.
and improve heuristics for sending chunks where the chunksize
depends on the number of remaining tests rather than fixed numbers.
This reduces the number of master -> node messages (but not the
reverse direction)
