Ответ
На последнем проекте мы использовали GitLab CI для полной автоматизации тестирования. Pipeline был настроен по принципу «чем раньше найден баг, тем дешевле его исправить».
Структура pipeline выглядела так:
-
Стадия
lint(валидация кода):- Запускался
flake8для Python-кода приложения и самих автотестов. - При обнаружении критичных нарушений стиля сборка останавливалась.
- Запускался
-
Стадия
unit(модульные тесты):- Запускались быстрые юнит-тесты приложения (
pytest). - Сборка падала, если покрытие падало ниже заданного порога (например, 80%).
unit-test: stage: unit script: - pytest --cov=app --cov-fail-under=80 tests/unit/ artifacts: reports: junit: report.xml paths: - coverage/
- Запускались быстрые юнит-тесты приложения (
-
Стадия
api-test(интеграционное тестирование API):- Запускался набор API-тестов, написанных на
pytest+requests, против развернутого на тестовом стенде приложения. - Для изоляции использовалась отдельная тестовая БД, которая наполнялась фикстурами перед прогоном.
- Запускался набор API-тестов, написанных на
-
Стадия
ui-test(UI-тестирование):- Запускались end-to-end тесты на Playwright в headless-режиме в Docker-контейнере.
- Видеозапись прохождения тестов и скриншоты при падении сохранялись как артефакты для упрощения отладки.
-
Стадия
performance(тесты производительности):- Запускалась по расписанию (например, ночью) или вручную перед релизом.
- Использовался
k6для нагрузочного тестирования ключевых сценариев.
Ключевые практики:
- Параллельное выполнение: Стадии
unit,api-testиui-testзапускались параллельно на разных раннерах для скорости. - Артефакты и отчеты: Все стадии генерировали JUnit-отчеты, которые агрегировались в GitLab UI. Для UI-тестов также генерировался Allure-отчет.
- Уведомления: При падении любой стадии в корпоративный Slack приходило оповещение с ссылкой на упавший пайплайн.
- Тегирование и ручной запуск: Критичные, но долгие тесты (например, полный регресс) можно было запустить вручную с тегом
manualдля определенных веток.