Как настроить отдельные репозитории для автотестов с разными фреймворками и зависимостями?
Что проверяют
Умеете ли вы вести автотесты как нормальный программный проект: воспроизводимая сборка, изолированные зависимости, связь с версией приложения. Следом спрашивают, как тесты из отдельного репозитория узнают, какую сборку проверять, и где живёт общий код.
Как отвечать
Сначала обоснуйте разделение. Отдельный репозиторий оправдан, когда у тестов свой стек и цикл: UI на Playwright с TypeScript, API на Java с REST Assured, нагрузка на Python. Если тесты пишут разработчики под один сервис, их удобнее держать рядом с кодом.
Дальше по каждому репозиторию:
- зависимости с lock-файлом:
package-lock.jsonи установка черезnpm ci; Maven или Gradle с wrapper-скриптомmvnwилиgradlew; для Pythonpyproject.tomlс lock-файлом Poetry или uv. Версии фиксированы; - версия среды:
.nvmrc,.python-versionили сразу Docker-образ раннера. Официальный образ Playwright берите с той же версией, что в зависимостях, иначе браузеры не совпадут; - общий код: клиенты API, генераторы данных и настройки отчётов выносятся в библиотеку во внутреннем реестре пакетов, а не копируются;
- конфигурация: адреса стендов и учётки через переменные окружения и секреты CI;
- CI: у каждого репозитория свой пайплайн, его запускает пайплайн продукта после деплоя на стенд. В GitLab это
triggerдля multi-project pipeline, в GitHub Actionsrepository_dispatchилиworkflow_dispatch. Версия сборки передаётся параметром; - отчёты и обновления: общий Allure для всех репозиториев, обновления зависимостей через Renovate или Dependabot.
Где спотыкаются
Не связывают тесты с версией продукта. Фича ещё в ветке, тесты на неё уже в main тестового репозитория и падают на стенде со старой сборкой.
Размножают код авторизации и фабрик данных по трём репозиториям. Через полгода копии расходятся, и одна проверка ведёт себя по-разному.
Не фиксируют версии: у автора всё работает, а в CI приезжает новая мажорная версия фреймворка или браузера, и тесты падают без изменений в коде.