Configuration

There are a few command line options that change the behavior of the plugin. As with any pytest option, you can add the options to your pytest.ini if you want to have them applied to all tests automatically:

[pytest]
; always order tests with dependency markers
addopts = --order-dependencies

--order-scope

By default, tests are ordered per session, e.g. across all modules in the test run. Sometimes, you want to order tests per module or per test class instead. Consider that you have a growing number of test modules that you want to run simultaneously, with tests ordered per module. Per default you would need to make sure that the order numbers increases globally, if you want to run the test modules consecutively and order the test per module.

If you use the option --order-scope=module, there is no need for this. You can enumerate your tests starting with 0 or 1 in each module, and the tests will only be ordered inside each module. Using --order-scope=class additionally considers test classes–each test class is considered separately for ordering the tests. If a module has both test classes and separate test functions, these test functions are handled separately from the test classes. If a module has no test classes, the effect is the same as if using --order-scope=module.

For example consider two test modules:

tests/test_module1.py:

import pytest

@pytest.mark.order(2)
def test2():
    pass

@pytest.mark.order(1)
def test1():
    pass

tests/test_module2.py:

import pytest

@pytest.mark.order(2)
def test2():
    pass

@pytest.mark.order(1)
def test1():
    pass

Here is what you get using session and module-scoped sorting:

$ pytest tests -vv
============================= test session starts ==============================
...

tests/test_module1.py:9: test1 PASSED
tests/test_module2.py:9: test1 PASSED
tests/test_module1.py:5: test2 PASSED
tests/test_module2.py:5: test2 PASSED
$ pytest tests -vv --order-scope=module
============================= test session starts ==============================
...

tests/test_module1.py:9: test1 PASSED
tests/test_module1.py:5: test2 PASSED
tests/test_module2.py:9: test1 PASSED
tests/test_module2.py:5: test2 PASSED

--order-scope-level

This is an alternative option to define the order scope. It defines the directory level which is used as the order scope, counting from the root directory. The resulting scope is between the session and module scopes defined via --order-scope, where --order-scope-level=0 is the same as session scope, while setting the level to the number of test directory levels would result in module scope.

Consider the following directory structure:

order_scope_level
  feature1
    __init__.py
    test_a.py
    test_b.py
  feature2
    __init__.py
    test_a.py
    test_b.py

with the test contents:

test_a.py:

import pytest

@pytest.mark.order(4)
def test_four():
    pass

@pytest.mark.order(3)
def test_three():
    pass

test_b.py:

import pytest

@pytest.mark.order(2)
def test_two():
    pass

@pytest.mark.order(1)
def test_one():
    pass

The idea here is to test each feature separately, while ordering the tests across the test modules for each feature.

If we use session scope, we get:

$ pytest -v order_scope_level
============================= test session starts ==============================
...

order_scope_level/feature1/test_a.py::test_one PASSED
order_scope_level/feature2/test_a.py::test_one PASSED
order_scope_level/feature1/test_a.py::test_two PASSED
order_scope_level/feature2/test_a.py::test_two PASSED
order_scope_level/feature1/test_b.py::test_three PASSED
order_scope_level/feature2/test_b.py::test_three PASSED
order_scope_level/feature1/test_b.py::test_four PASSED
order_scope_level/feature2/test_b.py::test_four PASSED

which mixes the features.

Using module scope instead separates the features, but does not order the modules as wanted:

$ pytest -v --order-scope=module order_scope_level
============================= test session starts ==============================
...

order_scope_level/feature1/test_a.py::test_three PASSED
order_scope_level/feature1/test_a.py::test_four PASSED
order_scope_level/feature1/test_b.py::test_one PASSED
order_scope_level/feature1/test_b.py::test_two PASSED
order_scope_level/feature2/test_a.py::test_three PASSED
order_scope_level/feature2/test_a.py::test_four PASSED
order_scope_level/feature2/test_b.py::test_one PASSED
order_scope_level/feature2/test_b.py::test_two PASSED

To get the wanted behavior, we can use --order-scope-level=2, which keeps the first two directory levels:

$ pytest tests -v --order-scope-level=2 order_scope_level
============================= test session starts ==============================
...

order_scope_level/feature1/test_b.py::test_one PASSED
order_scope_level/feature1/test_b.py::test_two PASSED
order_scope_level/feature1/test_a.py::test_three PASSED
order_scope_level/feature1/test_a.py::test_four PASSED
order_scope_level/feature2/test_b.py::test_one PASSED
order_scope_level/feature2/test_b.py::test_two PASSED
order_scope_level/feature2/test_a.py::test_three PASSED
order_scope_level/feature2/test_a.py::test_four PASSED

Note that using a level of 0 or 1 would cause the same result as session scope in this example, and any level greater than 2 would emulate module scope.

--order-group-scope

This option is also related to the order scope. It defines the scope inside which tests may be reordered. Consider you have several test modules which you want to order, but you don’t want to mix the tests of several modules because the module setup is costly. In this case you can set the group order scope to “module”, meaning that first the tests are ordered inside each module (the same as with the module order scope), but afterwards the modules themselves are sorted without changing the order inside each module.

Consider these two test modules:

tests/test_module1.py:

import pytest

@pytest.mark.order(2)
def test1():
    pass

def test2():
    pass

tests/test_module2.py:

import pytest

@pytest.mark.order(1)
def test1():
    pass

def test2():
    pass

Here is what you get using different scopes:

$ pytest tests -vv
============================= test session starts ==============================
...

tests/test_module2.py:9: test1 PASSED
tests/test_module1.py:9: test1 PASSED
tests/test_module1.py:5: test2 PASSED
tests/test_module2.py:5: test2 PASSED
$ pytest tests -vv --order-scope=module
============================= test session starts ==============================
...

tests/test_module1.py:9: test1 PASSED
tests/test_module1.py:5: test2 PASSED
tests/test_module2.py:9: test1 PASSED
tests/test_module2.py:5: test2 PASSED
$ pytest tests -vv --order-group-scope=module
============================= test session starts ==============================
...

tests/test_module2.py:9: test1 PASSED
tests/test_module2.py:5: test2 PASSED
tests/test_module1.py:9: test1 PASSED
tests/test_module1.py:5: test2 PASSED

The ordering of the module groups is done based on the lowest non-negative order number present in the module (e.g. the order number of the first test). If only negative numbers are present, the highest negative number (e.g. the number of the last test) is used, and these modules will be ordered at the end. Modules without order numbers will be sorted between modules with a non-negative order number and modules with a negative order number, the same way tests are sorted inside a module.

The group order scope defaults to the order scope. In this case the tests are ordered the same way as without the group order scope. The setting takes effect only if the scope is less than the order scope, e.g. there are three possibilities:

  • order scope “session”, order group scope “module” - this is shown in the example above: first tests in each module are ordered, afterwards the modules

  • order scope “module”, order group scope “class” - first orders tests inside each class, then the classes inside each module

  • order scope “session”, order group scope “class” - first orders tests inside each class, then the classes inside each module, and finally the modules relatively to each other

This option will also work with relative markers, and with dependency markers if using the --order-dependencies option.

Here is a similar example using relative markers:

tests/test_module1.py:

import pytest

@pytest.mark.order(after="test_module2.py::test1")
def test1():
    pass

def test2():
    pass

tests/test_module2.py:

import pytest

def test1():
    pass

@pytest.mark.order(before="test1")
def test2():
    pass

Here is what you get using different scopes:

$ pytest tests -vv
============================= test session starts ==============================
...

tests/test_module1.py:5: test2 PASSED
tests/test_module2.py:9: test1 PASSED
tests/test_module2.py:5: test2 PASSED
tests/test_module1.py:9: test1 PASSED
$ pytest tests -vv --order-group-scope=module
============================= test session starts ==============================
...

tests/test_module2.py:9: test1 PASSED
tests/test_module2.py:5: test2 PASSED
tests/test_module1.py:9: test1 PASSED
tests/test_module1.py:5: test2 PASSED

You can see that in the second run the second test module is run before the first because of the dependency, but the tests inside each module remain in the same order as before. Note that using module scope as in the example above doesn’t make sense here due to the dependencies between modules.

This will also work with dependency markers if using the --order-dependencies option.

Note

This option will not work together well with the sparse ordering option.

--order-dependencies

This defines the behavior if the pytest-dependency plugin is used. By default, dependency marks are only considered if they coexist with an order mark. In this case it is checked if the ordering would break the dependency, and is ignored if this is the case. Consider the following:

import pytest

def test_a():
    assert True

@pytest.mark.dependency(depends=["test_a"])
@pytest.mark.order("first")
def test_b():
    assert True

In this case, the ordering would break the dependency and is therefore ignored. This behavior is independent of the option. Now consider the following tests:

import pytest

@pytest.mark.dependency(depends=["test_b"])
def test_a():
    assert True

@pytest.mark.dependency
def test_b():
    assert True

By default, test_a is not run, because it depends on test_b, which is only run after test_b:

$ pytest tests -vv
============================= test session starts ==============================
...
test_dep.py::test_a SKIPPED
test_dep.py::test_b PASSED

If you use --order-dependencies, this will change–the tests will now be reordered according to the dependency and both run:

$ pytest tests -vv --order-dependencies
============================= test session starts ==============================
...
test_dep.py::test_b PASSED
test_dep.py::test_a PASSED

Note that a similar feature may be added to pytest-dependency - if this is done, this option will not be needed, but for the time being you can use both plugins together to get this behavior. Note that pytest-order does not replace pytest-dependency–it just adds ordering to the existing functionality if needed.

Note

pytest-dependency also has the possibility to add dependencies at runtime using pytest_dependency.depends. These dependencies cannot be detected at collection time and therefore are not included in ordering. The same is true for the dynamic compilation of marked parameters.

--indulgent-ordering

You may sometimes find that you want to suggest an ordering of tests, while allowing it to be overridden for good reason. For example, if you run your test suite in parallel and have a number of tests which are particularly slow, it might be desirable to start those tests running first, in order to optimize your completion time. You can use the pytest-order plugin to inform pytest of this.

Now suppose you also want to prioritize tests which failed during the previous run, by using the --failed-first option. By default, pytest-order will override the --failed-first order, but by adding the --indulgent-ordering option, you can ask pytest to run the sort from pytest-order before the sort from --failed-first, allowing the failed tests to be sorted to the front (note that in pytest versions from 6.0 on, this seems not to be needed anymore, at least in this specific case).

--sparse-ordering

Ordering tests by ordinals where some numbers are missing by default behaves the same as if the the ordinals are consecutive. For example, these tests:

import pytest

@pytest.mark.order(3)
def test_two():
    assert True

def test_three():
    assert True

def test_four():
    assert True

@pytest.mark.order(1)
def test_one():
    assert True

are executed in the same order as:

import pytest

@pytest.mark.order(1)
def test_two():
    assert True

def test_three():
    assert True

def test_four():
    assert True

@pytest.mark.order(0)
def test_one():
    assert True

e.g. you get:

$ pytest tests -vv
============================= test session starts ==============================
...
test_module.py:13: test_one PASSED
test_module.py:3: test_two PASSED
test_module.py:6: test_three PASSED
test_module.py:9: test_four PASSED

The gaps between numbers, and the fact that the starting number is not 0, are ignored. This is consistent with the current behavior of pytest-ordering.

If you use the --sparse-ordering option, the behavior will change:

$ pytest tests -vv --sparse-ordering
============================= test session starts ==============================
...
test_module.py:6: test_three PASSED
test_module.py:13: test_one PASSED
test_module.py:9: test_four PASSED
test_module.py:3: test_two PASSED

Now all missing numbers (starting with 0) are filled with unordered tests, as long as unordered tests are left. In the shown example, test_three is filled in for the missing number 0, and test_four is filled in for the missing number 2. This will also work for tests with negative order numbers (or the respective names). The missing ordinals are filled with unordered tests first from the start, then from the end if there are negative numbers, and the rest will be in between (e.g. between positive and negative numbers), as it is without this option.