IQ.Lvbs/pytest-xdist
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Improve description of testing with multiple CPU's

Browse Source 
Co-authored-by: Bruno Oliveira <nicoddemus@gmail.com>
This commit is contained in:
Adam Johnson
2020-07-24 19:46:49 +01:00
committed by GitHub
parent 78eaa4c0e2
commit 82730e5c6c
1 changed files with 22 additions and 20 deletions
Download Patch File Download Diff File Expand all files Collapse all files

42
README.rst
View File

@@ -67,33 +67,35 @@ a checkout of the `pytest-xdist repository`_ ::
Speed up test runs by sending tests to multiple CPUs Speed up test runs by sending tests to multiple CPUs
---------------------------------------------------- ----------------------------------------------------
To send tests to multiple CPUs, type:: To send tests to multiple CPUs, use the ``-n`` (or ``-numprocesses``) option::
pytest -n NUM pytest -n NUMCPUS
Especially for longer running tests or tests requiring Pass ``-n auto`` to use as many processes as your computer has CPU cores. This
a lot of I/O this can lead to considerable speed ups. This option can can lead to considerable speed ups, especially if your test suite takes a
also be set to ``auto`` for automatic detection of the number of CPUs. noticeable amount of time.
If a test crashes the interpreter, pytest-xdist will automatically restart If a test crashes a worker, pytest-xdist will automatically restart that worker
that worker and report the failure as usual. You can use the and report the test’s failure. You can use the ``--max-worker-restart`` option
``--max-worker-restart`` option to limit the number of workers that can to limit the number of worker restarts that are allowed, or disable restarting
be restarted, or disable restarting altogether using ``--max-worker-restart=0``. altogether using ``--max-worker-restart 0``.
By default, the ``-n`` option will send pending tests to any worker that is available, without By default, using ``--numprocesses`` will send pending tests to any worker that
any guaranteed order, but you can control this with these options: is available, without any guaranteed order. You can change the test
distribution algorithm this with the ``--dist`` option. It takes these values:
* ``--dist=loadscope``: tests will be grouped by **module** for *test functions* and * ``--dist no``: The default algorithm, distributing one test at a time.
by **class** for *test methods*, then each group will be sent to an available worker,
guaranteeing that all tests in a group run in the same process. This can be useful if you have
expensive module-level or class-level fixtures. Currently the groupings can't be customized,
with grouping by class takes priority over grouping by module.
This feature was added in version ``1.19``.
* ``--dist=loadfile``: tests will be grouped by file name, and then will be sent to an available * ``--dist loadscope``: Tests are grouped by **module** for *test functions*
worker, guaranteeing that all tests in a group run in the same worker. This feature was added and by **class** for *test methods*. Groups are distributed to available
in version ``1.21``. workers as whole units. This guarantees that all tests in a group run in the
same process. This can be useful if you have expensive module-level or
class-level fixtures. Grouping by class takes priority over grouping by
module.
* ``--dist loadfile``: Tests are grouped by their containing file. Groups are
distributed to available workers as whole units. This guarantees that all
tests in a file run in the same worker.
Making session-scoped fixtures execute only once Making session-scoped fixtures execute only once
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^