Базово пайплайн чаще всего состоит из 4 шагов:
1. Сборка образа приложения
2. Запуск приложения
3. Сборка образа тестов
4. Запуск автотестов
Теперь вопрос — что тут можно реально ускорить?
Если говорим про Python, то первое что можно оптимизировать — сборку образов.
Большинство до сих пор используют pip, но есть еще как минимум:
— Poetry
— uv
И вот uv сейчас выглядит очень интересно. За счет того что он написан на Rust — установка зависимостей работает в несколько десятков раз быстрее.
На практике только за счет замены pip - uv можно спокойно срезать около минуты на старте сервиса и сборке контейнера.
Ту же самую оптимизацию можно провернуть и для образа автотестов.
Второй момент, который кажется очевидным, но как выяснилось — не для всех 😄
Python тесты можно запускать параллельно.
Золотой стандарт сейчас — pytest-xdist
Он позволяет реально запускать тесты в несколько процессов/воркеров.
Даже на обычном маке ускорение может быть x4-x8 в зависимости от количества ядер.
Пример:
pytest -n auto
или
pytest -n 8
Если используете аллюр:
pytest -n auto --alluredir=allure-results
Полезные плагины:
— pytest-parallel
— pytest-concurrent
— pytest-asyncio-concurrent
Но тут важно понимать — они подходят только если тесты не конфликтуют между собой и могут безопасно работать конкурентно.
Следующий уровень оптимизации — запускать не все тесты.
Например:
у вас 1000+ тестов, но изменения затронули только платежи.
Зачем гонять вообще весь регресс?
Можно размечать тесты по фичам через markers и запускать только нужные.
Пример:
@pytest.mark.payments
def test_create_invoice():
...
Запуск:
pytest -m payments
Или через Allure labels/tags:
@allure.feature("Payments")
@allure.story("Invoices")
Еще один огромный bottleneck — подготовка тестовых данных.
На сложных интеграционных сценариях подготовка данных может занимать больше времени чем сами тесты.
Что можно сделать:
— вынести подготовку данных в отдельный сервис
— складывать подготовленные данные в БД
— отдавать их тестам через API
— использовать session fixtures
— готовить данные фоном во время тестовой сессии
Например:
пока идут первые тесты — в фоне уже готовятся данные для следующих.
Хранить это можно хоть в SQLite, Redis или отдельной тестовой БД.
Еще хороший кейс — авторизация.
Очень часто вижу как тест:
— логинится
— получает токен
— делает запрос
— заканчивается
И так 500 раз подряд 😄
Хотя можно сделать клиент который:
— фоново обновляет токен
— кеширует его
— следит за TTL
— отдает уже актуальный access token тестам
В итоге минус сотни лишних запросов в auth сервис.
Если суммировать, то основные точки ускорения это:
- Быстрая сборка образов
- Параллельность
- Конкурентность
- Запуск только нужных тестов
- Предподготовка тестовых данных
- Фоновые задачи
- Кеширование авторизации
И за счет этого можно очень сильно срезать время прохождения пайплайна и улучшить TTM выкатки
TG-сообщество | Обучение |Отзывы