Тест кейсы как код

[golikovichev]

Тема близкая. У нас один backend на 7 команд, я один QA. До какого-то момента поддерживал ручные тесты в TestRail параллельно с pytest, и расхождение между ними съедало больше времени, чем сами тесты.

Пробовал два захода в сторону «всё в коде». Первый: pytest как единственное место правды (вместо YAML/Gherkin). Плюс - тестировщики уже видят pytest-репорт когда автотесты бегут, не нужна синхронизация. Минус - ручные шаги в pytest-кейсе как комментарии или skip-маркеры выглядят как костыль, бизнес-логику в них не описать без болтовни.

Второй: конвертация существующих фикстур в pytest. У нас лежали Postman-коллекции с готовыми тест-сценариями (CRUD на каждый домен), я написал утилиту которая разворачивает их в pytest-модули. Получается тест-кейс как код, но первичный «человекочитаемый» артефакт это Postman collection (его QA пишет в привычном UI). Минус: Postman-коллекции в git выглядят страшно (json с авто-сгенерированными id), сравнивать diff между ветками невозможно.

У вас плагин в IDE решает ровно эту проблему diff, но только для YAML формата. Получается выбор: либо привычный TMS-подобный UI (Postman, TestRail) с git-несовместимыми артефактами, либо git-совместимый YAML с новой кривой обучения для тестировщиков.

Вопрос про общие шаги: если в общем кейсе меняется API-сигнатура, как у вас рассылается оповещение командам что нужно перезапустить тесты, использующие этот кейс? У нас на pytest это решается через зависимости фикстур, но в декларативном YAML аналогичный механизм нужен отдельный.

[kuzin_ivan]

В плагине не только YAML, можно использовать и python (pytest) и gherkin (behave). Но с ограничениями конечно, например в pytest можно использовать только статичные параметры и степы прямо из тела теста. Так же прямо в визуальном редакторе можно накидывать тесты и они автоматически будут в python коде

Например

# savetest_status: new
# savetest_author: user
# savetest_created_at: 2025-11-26T08:27:12Z
# savetest_description: Описание
import allure
import pytest

@allure.suite("4980b83f-6842-46a7-a4f5-1114ec8ee209")
@allure.story("Gettmp_Позитивные")
class TestGettmpPozitivnye:
    
    @allure.testcase("8f917f70-74e3-40e9-8473-f9b7eeca7c5a")
    @allure.title("Проверка получения списка сущностей с обязательными параметрами")
    @allure.description("Описание")
    @allure.severity(allure.severity_level.CRITICAL)
    @allure.tag("manual")
    @pytest.mark.manual
    def test_proverka_tm1(self):
        with allure.step("Предусловия"):
            pass
        with allure.step("У сущности есть статусы 'A_CREATING', 'A_CREATED', 'A_CLOSING', 'A_CLOSED', 'A_CANCELING'"):
            pass
        with allure.step("Ожидаемый результат: Результат предусловия"):
            pass
        with allure.step("\"Вызвать метод GettmpQuery с параметрами:\n"
                         "- tmp1: валидный ID \n"
                         "- tmp2: значение в диапазоне от 1 до restQuery.maxPageSize\n"
                         "- page: значение >= 0\""):
            pass

А вот этот же кейс в визуальном редакторе

Далее приходит человек, который готов автоматизировать. Он реализует этот кейс и он из ручного превращается в автоматический. Степы можно оставить или убрать, зависит от ваших внутренних правил

Про общие кейсы. Может я не верно понял вопрос. Но в контексте статьи под общими кейсами имелись ввиду неавтоматизированные общие кейсы (т.е. ручные). По сути эти кейсы проходятся руками тестировщиком в тест-ране, когда он проходит ручные кейсы.

Если же кейс стал автоматическим, то предполагается это решать стандартными практиками кода, и ТМС система уже только фиксирует результат прохождения

[golikovichev]

Спасибо за развёрнутый ответ. Hybrid режим (YAML + python + gherkin) выглядит как сильный middle ground. Раз тестировщики не готовы покинуть UI, плагин даёт generated python код в фоне, и git diff читается.

Про static parameters в pytest. Это как раз ограничение, которое привело меня к Postman -> pytest конвертации. Параметры держу в Postman collection environment files (там faker-генерация, conditional переменные, env-specific configs), а конвертер разворачивает их в pytest fixtures с динамическими значениями. JSON Postman остаётся «человекочитаемым» источником правды (тестировщик правит в Postman UI), сгенерированный python модуль идёт в git как regular pytest код.

Получается ваш подход и мой решают одну проблему с двух сторон. Вы маскируете python код визуальным редактором, я Postman JSON через кодогенерацию. У вас выходит лучше для тех, кто всю жизнь в TMS UI. У меня для команд, где Postman уже используется как «исходник» тестов.

Утилита OSS, если интересно посмотреть подход: https://github.com/golikovichev/postman2pytest

И вопрос. В SaveTest как обрабатываются динамические параметры? Если тест требует runtime-generated данных (UUID, current timestamp, random email), это идёт через generated python fixtures или есть отдельный механизм?