В CI нужен быстрый набор тестов на каждый коммит и полный набор по расписанию. Как организовать такой отбор без дублирования тестов?
Используйте метки тестов или другую единую метаинформацию, по которой CI формирует разные наборы запуска. Один тест должен существовать в одном экземпляре, а принадлежность к быстрому, полному или специализированному набору задаётся его атрибутами.
По мере роста автотестов один и тот же набор стало невозможно эффективно запускать на каждом изменении: полный прогон увеличивает время обратной связи и расход вычислительных ресурсов. Попытка решить это копированием тестов приводит к расхождению сценариев и усложняет сопровождение.
Метаки и категории появились как способ отделить описание теста от политики его запуска. Тест хранит проверяемое поведение, а CI определяет, какие категории запускать в конкретном событии.
Быстрый набор должен давать полезный сигнал за приемлемое время, а полный — проверять более широкий объём, включая длительные, редкие или зависимые от окружения сценарии. Если создавать отдельные копии тестов для разных прогонов, исправление в одном экземпляре легко не попадёт в другой.
Если же выбирать тесты только по именам файлов или случайным спискам в CI, правила отбора становятся неявными. В результате тест может быть ошибочно исключён из обязательного прогона, а изменение состава набора останется незаметным для команды.
Каждому тесту назначают одну или несколько меток с понятной семантикой, например быстрый, полный, критический или нестабильный. CI запускает тесты по фильтру меток: для проверки каждого коммита выбирается быстрый и критический набор, а по расписанию — полный набор.
Важно заранее определить правила пересечения категорий. Например, критический тест может одновременно входить в быстрый и полный набор, тогда как длительный тест — только в полный. При этом метка должна описывать свойство теста или его место в стратегии, а не временное решение вроде имени конкретной ветки.
Состав каждого набора следует проверять автоматически. Полезны контроль количества тестов, отчёты об исключённых сценариях и отдельный процесс пересмотра меток. Нестабильные тесты не следует навсегда прятать за специальной меткой: их нужно исправлять, а временное исключение — делать видимым и ограниченным по сроку.
Основной компромисс связан с длительностью и полнотой. Чем меньше быстрый набор, тем быстрее обратная связь, но тем выше вероятность пропустить дефект до полного прогона. Поэтому границы наборов определяют по риску изменений, критичности функций и статистике найденных дефектов, а не только по количеству тестов.
Команда запускала все 900 интеграционных и UI-тестов после каждого изменения. Прогон занимал около часа, поэтому разработчики стали игнорировать результаты CI. Рассматривались три варианта: копировать тесты в отдельные каталоги, запускать случайную подвыборку или использовать метки.
Копирование дало бы простое разделение, но создало бы две версии одного поведения. Случайная подвыборка сократила бы время, однако не гарантировала проверку критичных сценариев. Выбрали единые тесты с метками: на каждый коммит запускались быстрые и критические проверки, а полный набор — после слияния и по расписанию.
Дополнительно команда настроила отчёт о тестах, не вошедших в быстрый прогон, и еженедельно пересматривала категории. В результате обязательная обратная связь стала быстрее, а полнота проверки сохранилась за счёт регулярных полных запусков без дублирования сценариев.
1. Достаточно ли пометить тест как быстрый, если он иногда выполняется долго?
Нет. Метка должна отражать наблюдаемое и поддерживаемое свойство теста. Если длительность нестабильна, нужно измерять её по истории запусков, исследовать внешние зависимости и не включать тест в быстрый набор только на основании единичного удачного прогона.
2. Следует ли исключать нестабильные тесты из быстрого набора?
Временно — иногда да, но это не должно скрывать проблему. Исключённый тест должен сохраняться в другом обязательном или регулярно контролируемом прогоне, иметь владельца и срок пересмотра. Иначе метка превращается в механизм маскировки дефектов самой тестовой системы.
3. Как избежать того, чтобы метки превратились в неуправляемый список?
Нужно ограничить словарь меток, описать назначение каждой и установить правила их изменения. Метки должны быть взаимно понятными: например, отдельно описывать скорость, критичность и область запуска, а не создавать множество комбинаций вроде отдельных меток для каждого CI-события. Периодический аудит выявляет устаревшие категории и тесты, которые больше не соответствуют заявленной стратегии.