Coverage

Нарушаю долгое молчание небольшим подведением итогов того, чем занимался на работе.

В прошлом квартале сфокусировались на внедрение сбора метрики покрытия: code coverage и покрытие API методов автотестами по Swagger документации (назовем его Swagger-coverage, для простоты).
Мы планировали внедрить сбор и code coverage и Swagger-coverage во всех сервисах критического пути. Но удалось сделать только добавить Swagger-coverage во все сервисы.

Как это работает:
1. берем актуальное описание API в Swagger документации;
2. в http-клиент для API-тестов добавляем handler, который логирует, какие эндпоинты вызываются в тестах, с какими параметрами и какие статус коды приходят;
3. сравниваем фактически вызванные эндпоинты с исходной схемой и строим отчет, в котором видно что покрыто, а что не покрыто (скрин 1).

Текущие показатели этой метрики видно на графике. Разброс от 22 до 92%

После вендрения хотели добавлять Quality Gates и фейлить билд если покрытие стало ниже чем было до этого. Но в результате обсуждение с архитекторами и разработчиками решили, что сделаем пока уведомление в корпоративный мессенджер в канал команды-владельца сервиса о том, что покрытие снизилось.

Как считаете приемлемо, что у сервиса крит пути в API-тестах хоть как-то вызывается 22% эндпоинтов, а остальные не вызываются? Или надо наращивать покрытие?

Преимущества Playwright

Как и обещал (хоть и с опозданием и после лёгких пинков от читателя), делюсь преимуществами, которые мы получили после перехода с Selenium на Playwright.

Итак, напомню контекст: у нас автотесты монолита запускаются в изоляции (почти).
Сначала собираются все компоненты, затем создаются и загружаются их Docker-образы.
Затем в тестах запускается docker-compose со всеми сервисами монолита, скачивается и запускается БД — и только после этого стартуют автотесты.
Тесты разделены на два уровня: API и UI.
В каждом уровне есть по 1–3 тест-сьюта, которые запускаются параллельно. Для каждого сьюта поднимается своё окружение, БД и запускаются тесты.
API-тесты в этом улучшении мы не трогали, поэтому оставим их за скобками.

Ещё важная ремарка: перед анализом я очистил данные от аномалий (несколько прогонов длились по 800+ и 1000+ минут), а также взял только успешные запуски на main — нашей основной интеграционной ветке, куда попадает уже проверенный и зарелизенный код.

Что мы получили:
1. Сокращение времени прохождения пайплайна.
Раньше среднее время составляло 22.88 минут, теперь — 20.46.
На графике 1 (который, конечно, нарисовал Perplexity) видно ситуацию "до" и "после".
Левый и правый "усы" показывают минимальное и максимальное время прохождений, цветная область — 25–75 персентили, а чёрточка внутри — медиану.
После внедрения Playwright медианное значение снизилось примерно на 3 минуты. То, что в Selenium было ниже 25-го перцентиля, теперь стало 75-м в Playwright.
Экономия выглядит умеренной, но если учесть что мы запускаем пайплайн около 30 000 раз в год (в 2024 году было так) — это примерно 60 000 минут, или 1000 часов экономии времени разработчиков ежегодно. Конечно, обратная связь о коде через 20 минут вместо 22 — совсем не радикальное сокращение, но в масштабе года результат приемлемый.

2. Снижение затрат на GitHub Actions.
Раньше у нас было два сьюта UI-тестов — каждый проходил около 10 минут (примерно 4,5 минуты на поднятие окружения и 6 минут на выполнение тестов). Итого — 20 оплачиваемых минут.
После перехода на Playwright остался один сьют с тем же количеством тестов, выполняющийся за 10-11 минут.
На втором графике — видно насколько сократилось потребление времени для выполнения этих тестов (и, соответственно, денег).
Максимальное значение в Playwright теперь ниже медианы Selenium.
Если взять стоимость минуты в 0.008 $, то:
30 000 запусков × 9 минут × 0.008 $ = 2160 $ экономии в год.
Неплохой результат за счёт одной только замены фреймворка.

3. Единый технологический стек.
Приведение всех тестов к единому инструменту и экосистеме — бесценно, особенно для поддержки и найма новых сотрудников.

И всё это — при 60 UI‑тестах.
А представьте, сколько бы мы сэкономили, если бы тестов было 600 😅