Flaky-тесты — не приговор: эксперименты по ускорению выпуска релизов

В сфере искусственного интеллекта произошло заметное событие. yzhanov 9 минут назад Flaky-тесты — не приговор: эксперименты по ускорению выпуска релизов Средний 6 мин 407 Блог компании hh. ru Тестирование IT-систем * Тестирование веб-сервисов * Тестирование мобильных приложений * Кейс Привет, Хабр! Меня зовут Юра Жанов, я занимаюсь автоматизацией тестирования в hh.

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

Технические детали

Но прежде, чем перейдем к их описанию, приведу схему запуска тестов до. :info: Глоссарий:internal retry (внутренний ретрай) — перезапуск упавшего теста средствами тест-раннера в рамках одного прогонаretry job — автоматически создаваемый проект в Jenkins, который запускает только упавшие тестыстабильность теста — процент успешных запусков за последние две неделикарантин — реестр временно отключённых тестов. Работает как в ручном режиме через специальный UI, так и в автоматическом.

Подробнее об этом рассказывал мой коллега в статьеКак мы жили раньшеДолгое время наша схема выглядела так: во время основного прогона в Jenkins упавшие тесты получали до трёх внутренних ретраев. Если и это не помогало, собирали их в отдельный retry job, который запускали вручную. Дальше — цикл анализа: если проблема в тесте — фиксим или отправляем в карантин, если в продукте — переоткрываем задачу.

Со временем мы начали давать тестам всё больше попыток и остановились на трёх внутренних ретраях. Это работало, но приоритет сместился на автоматический релизный конвейер, участие человека свелось к минимуму. Пришлось экспериментировать.

Отраслевые последствия

Почему «просто почините тесты lol» уже не работаетстабилизация тестов в hh. ru — непрерывный процесс, поставленный на поток: по проблемным тестам автоматически заводятся задачи на владельцевтесты пишут более 60 тестировщиков — каждый в своей зоне ответственности, а также более 200 контрибьюторовколичество тестовых классов превысило 2700, а тестовых методов уже более 13 тысячдаже стабильные тесты раз в год «стреляют»Поэтому пришлось искать системные решения на уровне фреймворка. Эксперимент №1: ретраим до позелененияГипотеза: если не ограничивать количество попыток, среднее число упавших тестов снизится.

Мы дали проблемным тестам гоняться по кругу, пока очередь не опустеет. Результаты:время билда увеличилось в среднем на 3 минутыбольшинство перезапущенных тестов проходили со второй попытки, но были рекордсмены, которым для успеха потребовалась 17 попытка 🙂 (в реальных условиях такие тесты автоматически улетают в карантин)Вывод: интересно, но слишком дорого по времени. Эксперимент №2: ретраим класс целикомГипотеза: если упал хотя бы один метод, перезапуск всего класса повысит стабильность.

Идея заключалась в том, что при написании тестов не везде могла быть соблюдена атомарность тестовых методов.

Этот прогресс даёт важные сигналы о будущем отрасли, и технологический мир внимательно наблюдает.