Тяжелые времена требуют тяжелых решений. Не всегда архитектура приложений и тестового окружения идеальная. Они могут быть из рук вон плохими и не гибкими. А для их тестирования приходится переступать через гордость тестировщика и нарушать базовые принципы тестирования программного обеспечения.

Проблема, которой нет

Во-первых, каждый уважающий себя тестировщик должен знать, что такое “пирамида тестирования ПО”. А именно, что количество простых тестов, начиная от модульных, должно быть значительно больше, чем последующих API, затем UI и E2E тестов. Это объясняется тем, что стоимость разработки, выполнения и поддержки таких тестов ниже, они работают быстрее, да и, как правило уже на самом раннем этапе разработки и тестирования позволяют отлавливать большую часть ошибок. При этом, самые длинные тесты, которые последовательно, следуя бизнес-логике покрывают длинную последовательность действий и состояний - E2E обычно составляют самую маленькую часть тестирования. В первую очередь потому, что все их составляющие уже были (часто неоднократно) проверены меньшими и более простыми тестами. Во вторую, что действительно критичная бизнес-логика, коей и должны являться E2E тесты, как правило - это всего пара сценариев, которые, как мне кажется, с большой долей вероятности будут составлять ваш "дымовой набор" (smoke) для предрелизного тестирования (acceptance regression).

Чтобы слопать слона по кусочкам, каждый кусочек должен иметь возможность быть проверенным независимо. Обычно это так и есть - для функции пишутся несколько юнит-тестов, перебирающих параметры (например используя области эквивалентности и гранитные значения). Для интеграционных тестов (когда мы проверяем несколько компонентов\функций), скорее всего, вы будете использовать заглушки и моки. Для того, чтобы проверить состояние системы и её бизнес-логику, формат ответов и дизайн (например для проверки покрытия используя графы переходов или таблицу решений), скорее всего уже на уровне UI, для получения нужного состояния наверняка нужно будет предварительно как предусловие подёргать несколько API эндпоинтов и скормить системе нужные данные, чтобы получить нужное состояние. И только в совсем редких случаях как E2E сценарий мы будем писать тест, который пройдёт от логина до получения чуть ли не физического результата - зажженного светофора, выдачи денег банкоматом, или просто получения сообщения “прожиг успешно завершен неудачей”.

При этом, скорее всего, тесты - автоматизированные или даже ручные, если у вас несколько тестировщиков в команде, вы будете выполнять независимо. Чтобы состояние и данные не мешали выполнению тестов, тесты должны быть изолированными и атомарными. В худшем случае - это несколько тестовых изолированных окружений. В лучшем - отдельные компоненты, которые могут получать независимые состояния для своего контекста (функции, сессии, пользователя и прочая). При этом начало выполнения любого теста не должно зависеть от результатов выполнения другого. Ни из-за состояния системы, ни, тем более, от логики теста, который вы пишите. Это собственно и есть принцип изоляции. Тогда тесты будут маленькими, простыми, соответствовать принципу - “один тест - одна проверка” (то есть выполнять ещё один принцип - атомарности), и не должны будут проверять несколько раз, что мы перешли из состояния А в Б, чтобы потом из него попасть в состояние В, в котором будем проводить тестирования перехода в состояние Г.

Итак, это замечательная теория, которая работает в замечательных компаниях, командах. Конечно, даже у идеальных команд есть ограничения в коде или в разработанной системе, но в замечательных командах замечательные разработчики могут помочь и написать тестовые “ручки”, которые будут сбрасывать или выставлять нужные состояния для тестирования, а для уровня изолированности окружения у нас есть возможность развернуть тестовую лабораторию на нескольких серверах, или вовсе поднимать безграничное количество контейнеров или устройств в облаке. Желаю вам всегда работать в таком месте.

Но, скорее всего, на каком-то этапе всё может пойти не так. И теория разойдётся с практикой в какой-то части. А то и целиком и полностью.

Проблема, которая есть

Что ж, наш мир не идеальный. Компании и команды не идеальны, код не идеален, и вообще-то, по-честному, люди не идеальны, даже я бы сказал, дерьмо они редкостное. И с этим приходится жить и работать.

Допустим, у вас есть тестовое окружение с сотней тестов, которые выполняются в изолированной среде - за несколькими брэндмауэрами (как то, на котором крутим тесты, как то, где развёрнута система и та, которая тесты запускает - наш CI сервер), из-за которых происходит обращение к одной из платформ облачного тестирования. Если вы работали с такими системами, то, наверное, знаете, что развёртывание вируталки занимает какое-то время, поэтому не сильно резонно для каждого теста рвать соединение и пересоздавать его заново. Более того, даже если использовать только несколько развёрнутых виртуалок, скорость их работы оставляет желать лучшего. Ну а из-за нагромождений внутренних сетей, а так же разных регионов, эта связка, так скажем, начинает работать далеко не со скоростью света.

Что ж, запуск тестов становится медленнее, но всё же, никто нам не мешает сбрасывать и выставлять состояние для каждого теста внутри такой виртуалки. Да, но… система написана так, что у неё отсутствуют тестовые ручки, которые можно дёрнуть и выставить нужное состояние. Более того, для UI тестов нельзя просто перейти по нужному URL до нужной формы, а нужно обязательно покликать несколько экранов. Это всё занимает время, а в условиях тестового окружения подготовка к одному тесту может занять 1-2 минуты. Это уже звучит как огромная проблема, особенно, если мы пытаемся писать тесты хорошо, изолированно и атомарно, и следующая проверка - это, скажем ввод символа в поле. Катастрофа, заставляющая нас либо выкидывать такие тесты, либо ждать результатов часами.

Тут, похоже, пора переступать через свою гордость тестировщика, и лепить несколько проверок в один тест. Скажем, теперь тест будет заполнять двадцать полей и кликать по кнопке, чтобы перейти на другой экран. Думаю, вы понимаете, что во время ввода в поле, перекдывания чекбокса или переключателя может пойти что-то не так - отобразиться ошибка, например, потеряться текст, а при взаимодействии с другим компонентом состояние может опять изменится, и мы наверняка получим не совсем валидный результат. Итак, значит всё-таки как-то надо дробить нашу проверку на тесты, но при этом оставляя состояние системы для каждого из тестов, равную предыдущему состоянию. Итак, это мы можем сделать если будем сбрасывать контекст в рамках сессии. Это конечно неплохо, но тогда мы каждый раз будем поднимать виртуалку под сессию, объединяющую последовательность тестов. Пытаясь восстановить атомарность мы будем терять в производительности. Тогда есть ещё одна альтернатива - изолировать состояние по файлам, а ещё лучше - обернув тесты в тест-классы. Так скажем, SRP отдадим от уровня тестовой функции тестовому классу. Ведь, не случится ничего плохого, правда же? Да, я забыл сказать, что я пишу на python и использую pytest, так что будем говорить о нём дальше.

Проблема, которую мы создали

Итак, хороший и красивый атомарный тест, с которым вы обычно работаете выглядит следующим образом:

"""This module has no class, only test functions"""


def test_no_class_first():
    """This test always passes"""
    assert True


def test_no_class_second():
    """This test always fails"""
    assert False

Однако, для моего частного случая с моей неидеальной системой и командой мы решили использовать тест-классы. Они будут выглядеть примерно так:

"""This is a basic test"""


class TestBasic:
    """This is a basic test"""

    def test_basic(self):
        """This is basic test 1"""
        assert True

    def test_basic2(self):
        """This is basic test 2"""
        assert False

    def test_basic3(self):
        """This is basic test 3"""
        assert True

Лично у меня от такого идёт кровь из глаз, потому что я представлю какие проблемы это породит. Хотя выглядит, на первый взгляд неплохо. Но это на первый взгляд. Если вы позовёте тесты как обычно:

pytest tests

То тесты выполнятся последовательно, и, если в них была какая-то взаимосвязь, то она сохранится. Однако, если вы попробуете вызвать тесты в несколько потоков (pytest-xdist’ом), то последовательность перемешается.

pytest tests -n=auto

Чтобы этого избежать, нужно указать, как именно группировать тесты. Для этого нужно не забыть указать способ группировки.

pytest test -n=auto --dist loadscope 

Теперь, представим, что у нас двадцать шагов, зависимых друг от друга, и нам придётся пройтись по всем, даже есть один из первых тестов упал. Но в этом нет уже смысла, так как состояние было уже нарушено. Поэтому нам надо как-то в том случае реализовать логику “fail fast” - падать быстро. Для этого нам немного предстоит вмешаться в логику pytest’a и реализовать:

"""conftest.py"""

import pytest


def pytest_runtest_makereport(item, call):
    if "incremental" in item.keywords:
        if call.excinfo is not None:
            parent = item.parent
            parent._previousfailed = item

def pytest_runtest_setup(item):
    previousfailed = getattr(item.parent, "_previousfailed", None)
    if previousfailed is not None:
        pytest.xfail("previous test failed (%s)" % previousfailed.name)

Теперь те тест-классы, которые нужно быстро завалить, нужно предварительно пометить:

"""This is incremental test class"""

import pytest


@pytest.mark.incremental
class TestMarkedFailFast:
    """"This test class will fail fast"""
    
    def test_will_pass(self):
        """"This test will pass"""
        assert True

    def test_will_fail(self):
        """"This test will fail"""
        assert False

    def test_wont_run(self):
        """"This test won’t run"""
        assert True

Ещё одна проблема, которую мы создали - это бессмысленность использовать плагин pytest-rerunfailures. Если мы его решим использовать, то тест будет перезапущен вне контекста класса с совсем не тем состоянием, которое мы ожидали. Можно поломать ещё охапку копий на тему, насколько стоит использовать перезапуски или нет. В конце концов, пару падений мы переживём и перед релизом вручную перезапустим. Если падений много, возможно, что-то критичное поломалось, и мы быстро идентифицируем ошибку, а перезапускать придётся всё равно большую часть тестов - тогда уж можно и всё. Но если у вас тестов много - тысячи, а нестабильность всё же случается, и время жалко, если тест, конечно не регулярно нестабильно падает, то всё-таки лучше делегировать перезапуск машине. Но в нашем случае… таких вариантов, получается нет?

Проблема, которую я решил

Итак, для решения этой проблемы я написал плагин pytest-rerunclassfailures.

Чтобы его установить и начать пользоваться, просто ставим его через pip:

pip install pytest-rerunclassfailures

Чтобы запустить тесты с реранами, достаточно передать параметр —rerun-class-max с каким-нибудь числом реранов.

pytest tests --rerun-class-max=2

Ну или добавить явным образом в pytest.ini:

[pytest]
plugins = pytest-rerunclassfailures
addopts = --rerun-class-max=3

Также можно выставить дополнительные параметры, вроде задержки между реранами или тип логирования:

YTHONPATH=. pytest -s tests -p pytest_rerunclassfailures --rerun-class-max=3 --rerun-delay=1 --rerun-show-only-last

Плагин совместим с pytest-xdist , можно использовать в несколько потоков, но всегда указывайте --dist loadscope. После ошибки класс будет сброшен в начальное состояние, однако следующий тест будет падать при перезапуске, так как состояние класса было изменено в обход конструктора внутри фикстуры уровня функции. Впрочем, надеюсь, вы не используете эту плохую практику в вашем коде.

"""Test class with function (fixtures) attributes"""

from random import choice

import pytest

random_attribute_value = choice((42, "abc", None))


@pytest.fixture(scope="function")
def function_fixture(request):
    """Fixture to set function attribute"""
    request.cls.attribute = "initial"
    return "initial"


@pytest.fixture(scope="function")
def function_fixture_secondary(request):
    """Fixture to set function attribute"""
    request.cls.attribute = "secondary"
    return "secondary"


class TestFunctionFixturesAttributes:
    """Test class with function params attributes"""

    def test_function_fixtures_attribute_initial(self, function_fixture):  # pylint: disable=W0621
        """Test function fixture attribute at the beginning of the class"""
        assert self.attribute == "initial"
        assert function_fixture == "initial"

    def test_function_fixtures_attribute_recheck(self, function_fixture_secondary):  # pylint: disable=W0621
        """Test function fixture attribute after changing attribute value"""
        assert self.attribute == "secondary"  # type: ignore  # pylint: disable=E0203
        assert function_fixture_secondary == "secondary"
        self.attribute = random_attribute_value  # type: ignore  # pylint: disable=attribute-defined-outside-init
        # attribute is changed, but fixture is not
        assert self.attribute == random_attribute_value
        assert function_fixture_secondary == "secondary"

    def test_function_fixtures_attribute_forced_failure(self):
        """Test function fixture attribute to be forced failure"""
        assert False

@pytest.hookimpl(tryfirst=True)
def pytest_runtest_protocol(
    self, item: _pytest.nodes.Item, nextitem: _pytest.nodes.Item  # pylint: disable=W0613
) -> bool:

parent_class = item.getparent(pytest.Class)
for i in items[items.index(item) + 1 :]:
    if item.cls == i.cls:  # type: ignore
        siblings.append(i)

for i in range(len(siblings) - 1):
    # Before run, we need to ensure that finalizers are not called (indicated by None in the stack)
    nextitem = siblings[i + 1] if siblings[i + 1] is not None else siblings[0]
    siblings[i].reports = runtestprotocol(siblings[i], nextitem=nextitem, log=False)

item.ihook.pytest_runtest_logstart(nodeid=item.nodeid, location=item.location)
for index, rerun in enumerate(test_class[item.nodeid]):
    self.logger.debug("Reporting node results %s (%s/%s)", item.nodeid, len(test_class[item.nodeid]), index)
    for report in rerun:
        item.ihook.pytest_runtest_logreport(report=report)
item.ihook.pytest_runtest_logfinish(nodeid=item.nodeid, location=item.location)

В заключение

На этом всё. Надеюсь, мой плагин поможет вам немного, когда вы работаете с плохими архитектурными решениями, с плохим кодом и тестами. Если этот материал был вам полезен, то не забудьте поставить лайк этому посту, написать комментарий, а так же, если воодушевитесь - поделиться монеткой. Оригинал статьи тут.