Комментарии 5
Спасибо, отвечу по пунктам :)
Гоняются все автотесты, но мы не можем прогнать все 1400 в параллель, параллельно выполняться могут максимально 750 автотестов, то есть освобождается один эмулятор и его забирает новый тест, это что-то вроде максимальной пропускной способности
Для UI-автотестов импакт анализ тоже вполне релевантная тема, но тут надо понимать, что так или иначе мы повышаем риск того, что получим баг в целевой ветке, мы пока можем себе позволить запуск всех UI-автотестов, не будь такой возможности, я бы использовала импакт анализ для запуска UI-тестов, но совместила бы его со смоуком для нивелирования рисков
Да, на создание эмулятора правда нужно время, мы с коллегами рассматриваем вариант зачищения эмулятора и его переиспользования, но предварительно будем высчитывать время выигрыша от такой стратегии использования эмуляторов, при первом приближении разница во времени показалась незначительной
Не знаю как вы, а я последний месяц пишу тесты на React и Android только в Claude Sonnet. Кидаю ему исходник формы и он пишет все тесты за секунду. 90% работающие, надо лишь слегка подправить
Эмилия, спасибо за статью. Кажется, что добиться того, чтобы 1400 ui-тестов нормально гонялись на каждом билде к МРу - это немалая работа. :)
Расскажите, пожалуйста, еще про облачную/CI часть.
большое количество UI-автотестов на Android — около 1400. Чтобы
оптимизировать обработку такого значительного объема, мы запускаем в
облаке по 250 автотестов в 3 потока — это позволяет выполнять
одновременно 750 тестов. Под каждый автотест создается свой эмулятор,
который удаляется после завершения теста
3 потом по 250 - это 750 тестов за условный прогон, но всего тестов 1400+. Получается, для каждого билда надо 2 таких прогона? Либо гоняются не все тесты, а лишь часть?
На ваш взгляд, стоит ли запускать для МРа все 1400+ ui-тестов, или можно высчитать, в каких именно фичах/модулях были правки, и запустить только те ui-тесты, которые проверяют затронутый функционал? Для unit-тестов такое сделать можно (смотрим на затронутые модули), для ui-тестов это выглядит куда сложнее
Нет ли большого оверхеда по времени из-за создания своего эмулятора под каждый тест? Пока эмуль запустится и выйдет на связь с adb, может пройти какое то время, даже если эмуль "прогретый" (с сохраненным снапшотом состояния).
Спасибо, отвечу по пунктам :)
Гоняются все автотесты, но мы не можем прогнать все 1400 в параллель, параллельно выполняться могут максимально 750 автотестов, то есть освобождается один эмулятор и его забирает новый тест, это что-то вроде максимальной пропускной способности
Для UI-автотестов импакт анализ тоже вполне релевантная тема, но тут надо понимать, что так или иначе мы повышаем риск того, что получим баг в целевой ветке, мы пока можем себе позволить запуск всех UI-автотестов, не будь такой возможности, я бы использовала импакт анализ для запуска UI-тестов, но совместила бы его со смоуком для нивелирования рисков
Да, на создание эмулятора правда нужно время, мы с коллегами рассматриваем вариант зачищения эмулятора и его переиспользования, но предварительно будем высчитывать время выигрыша от такой стратегии использования эмуляторов, при первом приближении разница во времени показалась незначительной
Спасибо за пост. Подскажите можно ли запустить UI тесты для android без поддержки аппаратной виртуализации?
Работа с UI-автотестами под Android: от запрета мерджа к особенностям запуска