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