Как организовать запуск полного набора или отдельных наборов тестов по необходимости?

Что проверяют

Есть ли у вас система, по которой набор тестов подбирается под ситуацию: коммит, мерж, релиз, ночной прогон. Следом обычно спрашивают, сколько идёт полный прогон и что вы делаете, когда он стал слишком долгим.

Как отвечать

Каркас из трёх частей: разметка тестов, параметризованный запуск, расписание в CI.

Тесты помечают тегами по назначению и цене: smoke, regression, api, ui, slow, модуль продукта. Под ваш стек:

• pytest: @pytest.mark.smoke и запуск pytest -m "smoke and not slow". Маркеры регистрируются в pytest.ini, флаг --strict-markers ловит опечатки;
• JUnit 5 и TestNG: @Tag("smoke") или groups, из Maven mvn test -Dgroups=smoke, в Gradle includeTags внутри useJUnitPlatform; у TestNG ещё XML-сьюты;
• Playwright: тег @smoke в названии или опциях теста и npx playwright test --grep @smoke, отдельные projects под браузеры.

Запуск по необходимости делается параметром пайплайна, а не его копией: ручная джоба с переменной TEST_SUITE в GitLab, параметризованная сборка в Jenkins, workflow_dispatch с inputs в GitHub Actions.

Расписание по уровням:

• каждый коммит или MR: юнит, API и смоук, чтобы ответ приходил за минуты;
• мерж в основную ветку: регресс по затронутым модулям;
• ночь и перед релизом: полный набор со всеми браузерами и окружениями.

Долгий полный прогон режут параллельностью (pytest-xdist с -n auto, --shard в Playwright) и выбором тестов по изменённому коду. Результаты собирают в Allure или ReportPortal, чтобы видеть историю падений каждого теста.

Где спотыкаются

Делают тесты зависимыми друг от друга: второй берёт данные, созданные первым. Отдельный набор тогда не запустить, он падает без «предыдущего» теста.

Не договариваются о тегах. Через полгода рядом живут smoke, Smoke и sanity, и никто не знает, что именно гоняет смоук.

Держат флаки в общем наборе. Красный прогон перестают читать, и настоящий баг теряется среди «опять упало само». Нестабильные тесты выносят в карантин с задачей на починку.