Привет, Хабр! Меня зовут Юра Жанов, я занимаюсь автоматизацией тестирования в hh.ru.

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

Глоссарий:

• internal retry (внутренний ретрай) — перезапуск упавшего теста средствами тест-раннера в рамках одного прогона

• retry job — автоматически создаваемый проект в Jenkins, который запускает только упавшие тесты

• стабильность теста — процент успешных запусков за последние две недели

• карантин — реестр временно отключённых тестов. Работает как в ручном режиме через специальный UI, так и в автоматическом. Подробнее об этом рассказывал мой коллега в статье

Как мы жили раньше

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

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

Почему «просто почините тесты lol» уже не работает

• стабилизация тестов в hh.ru — непрерывный процесс, поставленный на поток: по проблемным тестам автоматически заводятся задачи на владельцев

• тесты пишут более 60 тестировщиков — каждый в своей зоне ответственности, а также более 200 контрибьюторов

• количество тестовых классов превысило 2700, а тестовых методов уже более 13 тысяч

• даже стабильные тесты раз в год «стреляют»

Поэтому пришлось искать системные решения на уровне фреймворка.

Эксперимент №1: ретраим до позеленения

Гипотеза: если не ограничивать количество попыток, среднее число упавших тестов снизится.

Мы дали проблемным тестам гоняться по кругу, пока очередь не опустеет.

Результаты:

• время билда увеличилось в среднем на 3 минуты

• большинство перезапущенных тестов проходили со второй попытки, но были рекордсмены, которым для успеха потребовалась 17 попытка ? (в реальных условиях такие тесты автоматически улетают в карантин)

Вывод: интересно, но слишком дорого по времени. Не взяли в прод.

Эксперимент №2: ретраим класс целиком

Гипотеза: если упал хотя бы один метод, перезапуск всего класса повысит стабильность.

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

Результаты: время прогона выросло почти на 5 минут, количество фейлов с двумя ретраями практически не уменьшилось.

Вывод: идея провалилась. Отказались.

Эксперимент №3: играемся с параллельностью

Гипотеза: повышенная нагрузка на инфраструктуру вызывает проблемы в тестах.

Тесты мы гоняем в параллели, и на момент проведения экспериментов у нас было задано 100 потоков. Решили посмотреть, насколько изменятся результаты, например, при 50 и 75 потоках.

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

Тут мы решили, что раз пробуем замедление, почему бы не посмотреть, что получится при увеличении потоков.При 150 потоках получили выигрыш в 4 минуты по длительности, но по среднему числу упавших тестов просели вдвое. Такой результат был ожидаемым, потому что на тот момент наша инфраструктура не была готова к такому повороту событий — мы получили ворох самых разнообразных ошибок и от приложений, и от окружения.

С тех пор, как проводился этот эксперимент, мы далеко ушли в плане мониторинга и прикрутили балансировку всевозможных узлов, задействованных в процессе, и теперь можем полноценно управлять нагрузкой.

Вывод: замедление даёт минимальный выигрыш по стабильности при сильном росте времени. Подход не взяли как основной.

Эксперимент №4: изоляция проблемных тестов

Гипотеза: если упавшие тесты отправить в конец очереди основного прогона и забрать у них внутренние ретраи — результаты улучшатся.

Схема похожа на текущую, но перезапуск осуществляется в рамках основного прогона, а не в отдельном retry job.

Результаты: количество failed-тестов улучшить не удалось, время прогона выросло примерно на 1 минуту.

Вывод: эффект оказался слабым. Не прижилось.

Эксперимент №5: адаптивные ретраи

Гипотеза: дополнительные попытки для тестов с пониженной стабильностью улучшат результаты.

Реализация выглядела примерно так:

int getRetryLimit() {
    int stability = getTestStability(testClass);
    if (stability > 80) return 2;
    if (stability > 70) return 3;
    return 4;
  }

Такой подход показал себя хорошо: средняя длительность прогона выросла на ~3 минуты, но при этом удалось снизить число упавших тестов более чем в 2 раза: с 3.8 до 1.6.

Важно понимать, что значительная часть успеха такого подхода заключается в «проталкивании» нестабильных тестов. Длительность прогона сильно зависит от их количества и процента стабильности каждого теста — это мы учли в будущих оптимизациях.

Позже мы уменьшили общее количество попыток до 4, что сэкономило ещё немного времени на проблемных тестах.

Эксперимент вышел успешным. Мы раскатили его и прожили с такой схемой несколько месяцев, продолжая собирать статистику. При этом не оставили попыток внести улучшения в процесс как с точки зрения скорости, так и удобства выпускающего релиз.

Финальный аккорд: автозапуск retry job

Анализ статистики показал: полностью отказаться от сбора упавших тестов в отдельный retry job не получится. Поэтому мы решили автоматизировать этот процесс. При создании ретрая мы через Jenkins API триггерим сборку с параметром delay в 3 минуты.

Задержку делаем по двум основным причинам:

1. Чтобы у выпускающего была возможность ознакомиться с предварительными результатами основного запуска.

2. Чтобы после основного запуска тестовый стенд слегка «остыл» от интенсивной нагрузки, создаваемой полным набором тестов.

Мы посчитали, что именно отдельный запуск первого retry job обеспечивает успех в 89% случаев для релизов с полным набором тестов. А для остальных 11% случаев мы сделали в специальном канале мессенджера автоматическое оповещение для владельцев упавших тестов — это позволяет оперативно подключиться и решить проблему. 

Итоги

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

И только комбинация схемы адаптивных ретраев и автозапуска retry job принесла желаемый эффект по двум важным метрикам:

• длительность прогона полного набора тестов по медиане сократилась на 20% — с 46 до 37 минут

• среднее количество упавших тестов уменьшилось с 14 до 6

А ещё мы стали меньше отвлекать от работы коллег для решения проблем с тестами. Тоже классный результат!

В завершении коротко упомяну ещё несколько идей для ускорения релизного автотестирования. Я на них подробно не останавливался в статье, но эти идеи также улучшили наши метрики.

Итак, мы:

• Сделали ограничение в 60 секунд для явных ожиданий в коде: этого достаточно для отработки любого процесса (почти). А если этого не хватает, можно либо унести тест на другой уровень, либо рассмотреть применение моков. Длительные ожидания создают дополнительную проблему, если у теста не идеальная стабильность — перезапуски удлиняют прогон, попадая в конец очереди

• Забрали у нестабильных за текущий день тестов право на внутренний перезапуск. Если у теста сегодня менее 20% стабильности, то применяем к нему подход fail fast и не мучаем ни его, ни причастных лиц, упрощая отправку пострадавшего в карантин

• Оптимизировали очередь на запуск в параллели для несовместимых друг с другом тестов

• Вернули фиксированное количество попыток: схема с автозапуском retry job показала отличные результаты и необходимость в дополнительных внутренних ретраях отпала

Как видим, flaky-тесты — не приговор. С ними можно жить комфортно, если грамотно настроить процессы и инфраструктуру.

На этом наши идеи по улучшению процесса автотестирования не заканчиваются. Мы продолжим делиться нашими находками в следующих статьях.

А как вы укрощаете нестабильные тесты в своих проектах? Какие подходы работают у вас лучше всего? Делитесь в комментариях — будет очень интересно почитать!