Параметризация тестов

Генерация комбинаций параметров в зависимости от командной строки

Предположим, мы хотим выполнить тест с разными параметрами вычислений, а диапазон параметров должен определяться аргументом командной строки. Для начала напишем простой тест вычислений (который ничего не делает):

# content of test_compute.py


def test_compute(param1):
    assert param1 < 4

Теперь добавим такую конфигурацию тестов:

# content of conftest.py


def pytest_addoption(parser):
    parser.addoption("--all", action="store_true", help="run all combinations")


def pytest_generate_tests(metafunc):
    if "param1" in metafunc.fixturenames:
        if metafunc.config.getoption("all"):
            end = 5
        else:
            end = 2
        metafunc.parametrize("param1", range(end))

Это означает, что мы запускаем только 2 теста, если не передаём --all:

$ pytest -q test_compute.py
..                                                                   [100%]
2 passed in 0.12s

Мы выполняем только два вычисления, поэтому видим две точки. Запустим полный диапазон:

$ pytest -q --all
....F                                                                [100%]
================================= FAILURES =================================
_____________________________ test_compute[4] ______________________________

param1 = 4

    def test_compute(param1):
>       assert param1 < 4
E       assert 4 < 4

test_compute.py:4: AssertionError
========================= short test summary info ==========================
FAILED test_compute.py::test_compute[4] - assert 4 < 4
1 failed, 4 passed in 0.12s

Как и ожидалось, при запуске всего диапазона значений param1 на последнем значении возникнет ошибка.

Разные варианты идентификаторов тестов

pytest формирует строку — идентификатор теста — для каждого набора значений в параметризованном тесте. Эти идентификаторы можно использовать с -k, чтобы выбрать конкретные случаи для запуска; они также указывают на конкретный случай при возникновении сбоя. Запуск pytest с параметром --collect-only покажет сгенерированные идентификаторы.

Для чисел, строк, булевых значений и None в идентификаторе теста используется их обычное строковое представление. Для других объектов pytest сформирует строку на основе имени аргумента:

# content of test_time.py

from datetime import datetime, timedelta

import pytest

testdata = [
    (datetime(2001, 12, 12), datetime(2001, 12, 11), timedelta(1)),
    (datetime(2001, 12, 11), datetime(2001, 12, 12), timedelta(-1)),
]


@pytest.mark.parametrize("a,b,expected", testdata)
def test_timedistance_v0(a, b, expected):
    diff = a - b
    assert diff == expected


@pytest.mark.parametrize("a,b,expected", testdata, ids=["forward", "backward"])
def test_timedistance_v1(a, b, expected):
    diff = a - b
    assert diff == expected


def idfn(val):
    if isinstance(val, (datetime,)):
        # note this wouldn't show any hours/minutes/seconds
        return val.strftime("%Y%m%d")


@pytest.mark.parametrize("a,b,expected", testdata, ids=idfn)
def test_timedistance_v2(a, b, expected):
    diff = a - b
    assert diff == expected


@pytest.mark.parametrize(
    "a,b,expected",
    [
        pytest.param(
            datetime(2001, 12, 12), datetime(2001, 12, 11), timedelta(1), id="forward"
        ),
        pytest.param(
            datetime(2001, 12, 11), datetime(2001, 12, 12), timedelta(-1), id="backward"
        ),
    ],
)
def test_timedistance_v3(a, b, expected):
    diff = a - b
    assert diff == expected

В test_timedistance_v0 мы позволили pytest сгенерировать идентификаторы тестов.

В test_timedistance_v1 мы указали ids в виде списка строк, которые использовались как идентификаторы тестов. Они лаконичны, но их может быть сложно поддерживать.

В test_timedistance_v2 мы указали ids в виде функции, которая может генерировать строковое представление для включения в идентификатор теста. Поэтому для значений datetime используется метка, сгенерированная с помощью idfn, но поскольку мы не сгенерировали метку для объектов timedelta, для них по-прежнему используется представление pytest по умолчанию:

$ pytest test_time.py --collect-only
=========================== test session starts ============================
platform linux -- Python 3.x.y, pytest-9.x.y, pluggy-1.x.y
rootdir: /home/sweet/project
collected 8 items

<Dir parametrize.rst-215>
  <Module test_time.py>
    <Function test_timedistance_v0[a0-b0-expected0]>
    <Function test_timedistance_v0[a1-b1-expected1]>
    <Function test_timedistance_v1[forward]>
    <Function test_timedistance_v1[backward]>
    <Function test_timedistance_v2[20011212-20011211-expected0]>
    <Function test_timedistance_v2[20011211-20011212-expected1]>
    <Function test_timedistance_v3[forward]>
    <Function test_timedistance_v3[backward]>

======================== 8 tests collected in 0.12s ========================

В test_timedistance_v3 мы использовали pytest.param, чтобы указать идентификаторы тестов вместе с фактическими данными, а не перечислять их отдельно.

Краткий перенос «testscenarios»

Ниже показан краткий перенос для запуска тестов, настроенных с помощью testscenarios — дополнения Роберта Коллинза для стандартного фреймворка unittest. Нам нужно лишь немного поработать, чтобы сформировать правильные аргументы для Metafunc.parametrize в pytest:

# content of test_scenarios.py


def pytest_generate_tests(metafunc):
    idlist = []
    argvalues = []
    for scenario in metafunc.cls.scenarios:
        idlist.append(scenario[0])
        items = scenario[1].items()
        argnames = [x[0] for x in items]
        argvalues.append([x[1] for x in items])
    metafunc.parametrize(argnames, argvalues, ids=idlist, scope="class")


scenario1 = ("basic", {"attribute": "value"})
scenario2 = ("advanced", {"attribute": "value2"})


class TestSampleWithScenarios:
    scenarios = [scenario1, scenario2]

    def test_demo1(self, attribute):
        assert isinstance(attribute, str)

    def test_demo2(self, attribute):
        assert isinstance(attribute, str)

Это полностью автономный пример, который можно запустить командой:

$ pytest test_scenarios.py
=========================== test session starts ============================
platform linux -- Python 3.x.y, pytest-9.x.y, pluggy-1.x.y
rootdir: /home/sweet/project
collected 4 items

test_scenarios.py ....                                               [100%]

============================ 4 passed in 0.12s =============================

Если просто собрать тесты, то среди вариантов тестовой функции будут также видны «advanced» и «basic»:

$ pytest --collect-only test_scenarios.py
=========================== test session starts ============================
platform linux -- Python 3.x.y, pytest-9.x.y, pluggy-1.x.y
rootdir: /home/sweet/project
collected 4 items

<Dir parametrize.rst-215>
  <Module test_scenarios.py>
    <Class TestSampleWithScenarios>
      <Function test_demo1[basic]>
      <Function test_demo2[basic]>
      <Function test_demo1[advanced]>
      <Function test_demo2[advanced]>

======================== 4 tests collected in 0.12s ========================

Обратите внимание: мы сообщили metafunc.parametrize(), что значения сценариев следует считать имеющими область видимости класса. В pytest-2.3 это приводит к упорядочиванию на основе ресурсов.

Отложенная настройка параметризованных ресурсов

Параметризация тестовых функций выполняется во время сбора тестов. Такие ресурсоёмкие объекты, как подключения к БД или подпроцессы, лучше настраивать только при фактическом запуске теста. Вот простой пример того, как этого добиться. Для этого теста требуется фикстура-объект db:

# content of test_backends.py

import pytest


def test_db_initialized(db):
    # a dummy test
    if db.__class__.__name__ == "DB2":
        pytest.fail("deliberately failing for demo purposes")

Теперь можно добавить конфигурацию тестов, которая создаст два вызова функции test_db_initialized, а также реализует фабрику для создания объекта базы данных при фактических запусках теста:

# content of conftest.py
import pytest


def pytest_generate_tests(metafunc):
    if "db" in metafunc.fixturenames:
        metafunc.parametrize("db", ["d1", "d2"], indirect=True)


class DB1:
    "one database object"


class DB2:
    "alternative database object"


@pytest.fixture
def db(request):
    if request.param == "d1":
        return DB1()
    elif request.param == "d2":
        return DB2()
    else:
        raise ValueError("invalid internal test config")

Для начала посмотрим, как это выглядит во время сбора тестов:

$ pytest test_backends.py --collect-only
=========================== test session starts ============================
platform linux -- Python 3.x.y, pytest-9.x.y, pluggy-1.x.y
rootdir: /home/sweet/project
collected 2 items

<Dir parametrize.rst-215>
  <Module test_backends.py>
    <Function test_db_initialized[d1]>
    <Function test_db_initialized[d2]>

======================== 2 tests collected in 0.12s ========================

А теперь — при запуске теста:

$ pytest -q test_backends.py
.F                                                                   [100%]
================================= FAILURES =================================
_________________________ test_db_initialized[d2] __________________________

db = <conftest.DB2 object at 0xdeadbeef0001>

    def test_db_initialized(db):
        # a dummy test
        if db.__class__.__name__ == "DB2":
>           pytest.fail("deliberately failing for demo purposes")
E           Failed: deliberately failing for demo purposes

test_backends.py:8: Failed
========================= short test summary info ==========================
FAILED test_backends.py::test_db_initialized[d2] - Failed: deliberately f...
1 failed, 1 passed in 0.12s

Первый вызов с db == "DB1" завершился успешно, а второй с db == "DB2" — с ошибкой. Наша функция фикстуры db создала каждое из значений БД на этапе настройки, а pytest_generate_tests сгенерировал два соответствующих вызова test_db_initialized на этапе сбора тестов.

Косвенная параметризация

Параметр indirect=True при параметризации теста позволяет параметризовать тест фикстурой, которая получает значения перед их передачей тесту:

import pytest


@pytest.fixture
def fixt(request):
    return request.param * 3


@pytest.mark.parametrize("fixt", ["a", "b"], indirect=True)
def test_indirect(fixt):
    assert len(fixt) == 3

Это можно использовать, например, чтобы выполнять более затратную настройку в фикстуре во время запуска теста, а не на этапе сбора тестов.

Применение indirect к отдельным аргументам

Очень часто для параметризации используются несколько имён аргументов. Параметр indirect можно применить к отдельным аргументам. Для этого нужно передать в indirect список или кортеж имён аргументов. В примере ниже функция test_indirect использует две фикстуры: x и y. Здесь мы передаём в indirect список, содержащий имя фикстуры x. Параметр indirect будет применён только к этому аргументу, а значение a будет передано соответствующей функции фикстуры:

# content of test_indirect_list.py

import pytest


@pytest.fixture(scope="function")
def x(request):
    return request.param * 3


@pytest.fixture(scope="function")
def y(request):
    return request.param * 2


@pytest.mark.parametrize("x, y", [("a", "b")], indirect=["x"])
def test_indirect(x, y):
    assert x == "aaa"
    assert y == "b"

Этот тест завершится успешно:

$ pytest -v test_indirect_list.py
=========================== test session starts ============================
platform linux -- Python 3.x.y, pytest-9.x.y, pluggy-1.x.y -- $PYTHON_PREFIX/bin/python
cachedir: .pytest_cache
rootdir: /home/sweet/project
collecting ... collected 1 item

test_indirect_list.py::test_indirect[a-b] PASSED                     [100%]

============================ 1 passed in 0.12s =============================

Параметризация методов тестирования с помощью конфигурации для каждого класса

Вот пример функции pytest_generate_tests, реализующей схему параметризации, похожую на параметризатор unittest Майкла Фурда, unittest parametrizer, но с гораздо меньшим количеством кода:

# content of ./test_parametrize.py
import pytest


def pytest_generate_tests(metafunc):
    # called once per each test function
    funcarglist = metafunc.cls.params[metafunc.function.__name__]
    argnames = sorted(funcarglist[0])
    metafunc.parametrize(
        argnames, [[funcargs[name] for name in argnames] for funcargs in funcarglist]
    )


class TestClass:
    # a map specifying multiple argument sets for a test method
    params = {
        "test_equals": [dict(a=1, b=2), dict(a=3, b=3)],
        "test_zerodivision": [dict(a=1, b=0)],
    }

    def test_equals(self, a, b):
        assert a == b

    def test_zerodivision(self, a, b):
        with pytest.raises(ZeroDivisionError):
            a / b

Генератор тестов ищет определение на уровне класса, в котором указаны наборы аргументов для каждой тестовой функции. Запустим его:

$ pytest -q
F..                                                                  [100%]
================================= FAILURES =================================
________________________ TestClass.test_equals[1-2] ________________________

self = <test_parametrize.TestClass object at 0xdeadbeef0002>, a = 1, b = 2

    def test_equals(self, a, b):
>       assert a == b
E       assert 1 == 2

test_parametrize.py:21: AssertionError
========================= short test summary info ==========================
FAILED test_parametrize.py::TestClass::test_equals[1-2] - assert 1 == 2
1 failed, 2 passed in 0.12s

Параметризация с несколькими фикстурами

Ниже приведён упрощённый пример из реальной практики: параметризованные тесты используются для проверки сериализации объектов между разными интерпретаторами Python. Мы определяем функцию test_basic_objects, которая должна выполняться с разными наборами аргументов для каждого из трёх аргументов:

• python1: первый интерпретатор Python, используемый для записи объекта в файл с помощью pickle
• python2: второй интерпретатор, используемый для чтения объекта из файла с помощью pickle
• obj: объект для записи и чтения

"""Module containing a parametrized tests testing cross-python serialization
via the pickle module."""

from __future__ import annotations

import shutil
import subprocess
import textwrap

import pytest


pythonlist = ["python3.11", "python3.12", "python3.13"]


@pytest.fixture(params=pythonlist)
def python1(request, tmp_path):
    picklefile = tmp_path / "data.pickle"
    return Python(request.param, picklefile)


@pytest.fixture(params=pythonlist)
def python2(request, python1):
    return Python(request.param, python1.picklefile)


class Python:
    def __init__(self, version, picklefile):
        self.pythonpath = shutil.which(version)
        if not self.pythonpath:
            pytest.skip(f"{version!r} not found")
        self.picklefile = picklefile

    def dumps(self, obj):
        dumpfile = self.picklefile.with_name("dump.py")
        dumpfile.write_text(
            textwrap.dedent(
                rf"""
                import pickle
                f = open({str(self.picklefile)!r}, 'wb')
                s = pickle.dump({obj!r}, f, protocol=2)
                f.close()
                """
            )
        )
        subprocess.run((self.pythonpath, str(dumpfile)), check=True)

    def load_and_is_true(self, expression):
        loadfile = self.picklefile.with_name("load.py")
        loadfile.write_text(
            textwrap.dedent(
                rf"""
                import pickle
                f = open({str(self.picklefile)!r}, 'rb')
                obj = pickle.load(f)
                f.close()
                res = eval({expression!r})
                if not res:
                    raise SystemExit(1)
                """
            )
        )
        print(loadfile)
        subprocess.run((self.pythonpath, str(loadfile)), check=True)


@pytest.mark.parametrize("obj", [42, {}, {1: 3}])
def test_basic_objects(python1, python2, obj):
    python1.dumps(obj)
    python2.load_and_is_true(f"obj == {obj}")

При запуске некоторые тесты будут пропущены, если установлены не все интерпретаторы Python. В противном случае будут выполнены все комбинации (3 интерпретатора × 3 интерпретатора × 3 объекта для сериализации/десериализации):

. $ pytest -rs -q multipython.py
ssssssssssss......sss......                                          [100%]
========================= short test summary info ==========================
SKIPPED [15] multipython.py:67: 'python3.11' not found
12 passed, 15 skipped in 0.12s

Параметризация необязательных реализаций/импортов

Если вы хотите сравнить результаты нескольких реализаций заданного API, можно написать тестовые функции, которые получают уже импортированные реализации и пропускаются, если реализацию невозможно импортировать или она недоступна. Предположим, у нас есть «базовая» реализация, а остальные (возможно, оптимизированные) должны выдавать похожие результаты:

# content of conftest.py

import pytest


@pytest.fixture(scope="session")
def basemod(request):
    return pytest.importorskip("base")


@pytest.fixture(scope="session", params=["opt1", "opt2"])
def optmod(request):
    return pytest.importorskip(request.param)

А вот базовая реализация простой функции:

# content of base.py
def func1():
    return 1

И её оптимизированная версия:

# content of opt1.py
def func1():
    return 1.0001

И, наконец, небольшой модуль с тестами:

# content of test_module.py


def test_func1(basemod, optmod):
    assert round(basemod.func1(), 3) == round(optmod.func1(), 3)

Если запустить его с включённым выводом информации о пропущенных тестах:

$ pytest -rs test_module.py
=========================== test session starts ============================
platform linux -- Python 3.x.y, pytest-9.x.y, pluggy-1.x.y
rootdir: /home/sweet/project
collected 2 items

test_module.py .s                                                    [100%]

========================= short test summary info ==========================
SKIPPED [1] test_module.py:3: could not import 'opt2': No module named 'opt2'
======================= 1 passed, 1 skipped in 0.12s =======================

Вы увидите, что у нас нет модуля opt2, поэтому второй запуск теста test_func1 был пропущен. Несколько замечаний:

• функции фикстур в файле conftest.py имеют область видимости «session», поскольку импортировать модуль несколько раз не нужно
• если у вас несколько тестовых функций и импорт пропущен, в отчёте увеличится число [1]
• в тестовых функциях также можно использовать параметризацию в стиле @pytest.mark.parametrize, чтобы параметризовать входные и выходные значения.

Назначение меток или идентификаторов отдельным параметризованным тестам

Используйте pytest.param, чтобы назначить метки или задать идентификатор отдельному параметризованному тесту. Например:

# content of test_pytest_param_example.py
import pytest


@pytest.mark.parametrize(
    "test_input,expected",
    [
        ("3+5", 8),
        pytest.param("1+7", 8, marks=pytest.mark.basic),
        pytest.param("2+4", 6, marks=pytest.mark.basic, id="basic_2+4"),
        pytest.param(
            "6*9", 42, marks=[pytest.mark.basic, pytest.mark.xfail], id="basic_6*9"
        ),
    ],
)
def test_eval(test_input, expected):
    assert eval(test_input) == expected

В этом примере у нас есть 4 параметризованных теста. Кроме первого, мы помечаем остальные три пользовательской меткой basic, а для четвёртого теста также используем встроенную метку xfail, чтобы указать, что ожидается сбой этого теста. Для наглядности мы задали идентификаторы некоторым тестам.

Затем запустим pytest в подробном режиме, указав только метку basic:

$ pytest -v -m basic
=========================== test session starts ============================
platform linux -- Python 3.x.y, pytest-9.x.y, pluggy-1.x.y -- $PYTHON_PREFIX/bin/python
cachedir: .pytest_cache
rootdir: /home/sweet/project
collecting ... collected 24 items / 21 deselected / 3 selected

test_pytest_param_example.py::test_eval[1+7-8] PASSED                [ 33%]
test_pytest_param_example.py::test_eval[basic_2+4] PASSED            [ 66%]
test_pytest_param_example.py::test_eval[basic_6*9] XFAIL             [100%]

=============== 2 passed, 21 deselected, 1 xfailed in 0.12s ================

В результате:

• Было собрано четыре теста
• Один тест был исключён из запуска, поскольку у него нет метки basic.
• Были выбраны три теста с меткой basic.
• Тест test_eval[1+7-8] завершился успешно, но его автоматически сгенерированное имя сбивает с толку.
• Тест test_eval[basic_2+4] завершился успешно.
• Ожидалось, что тест test_eval[basic_6*9] завершится с ошибкой, и он действительно завершился с ошибкой.

Параметризация условного возбуждения исключений

Используйте pytest.raises() вместе с декоратором pytest.mark.parametrize, чтобы писать параметризованные тесты, в которых одни тесты возбуждают исключения, а другие — нет.

contextlib.nullcontext можно использовать для проверки случаев, в которых не ожидается возбуждение исключения, но должно быть получено некоторое значение. Это значение задаётся параметром enter_result и будет доступно как целевая переменная оператора with (в примере ниже это e).

Например:

from contextlib import nullcontext

import pytest


@pytest.mark.parametrize(
    "example_input,expectation",
    [
        (3, nullcontext(2)),
        (2, nullcontext(3)),
        (1, nullcontext(6)),
        (0, pytest.raises(ZeroDivisionError)),
    ],
)
def test_division(example_input, expectation):
    """Test how much I know division."""
    with expectation as e:
        assert (6 / example_input) == e

В приведённом выше примере первые три тестовых случая должны выполняться без исключений, а четвёртый должен возбуждать исключение ZeroDivisionError, которое pytest ожидает получить.