Спасибо за статью! Интересен такой нюанс: как вы управляете правами доступа к /dev/kvm внутри контейнера с эмулятором?
Если правильно помню, прокинутый /dev/kvm залетает в докер-контейнер с id его владельца на хосте. При попытке запустить эмулятор от лица непривилегированного пользователя может не хватит прав на работу с KVM.
/dev/kvm доступен только при работе контейнера, при сборке самого докер-образа его еще нет, заранее права не выдать. А выдавать права во время работы контейнера в стиле `sudo chmod` тоже не хочется.
Эмилия, спасибо за статью. Кажется, что добиться того, чтобы 1400 ui-тестов нормально гонялись на каждом билде к МРу - это немалая работа. :)
Расскажите, пожалуйста, еще про облачную/CI часть.
большое количество UI-автотестов на Android — около 1400. Чтобы оптимизировать обработку такого значительного объема, мы запускаем в облаке по 250 автотестов в 3 потока — это позволяет выполнять одновременно 750 тестов. Под каждый автотест создается свой эмулятор, который удаляется после завершения теста
3 потом по 250 - это 750 тестов за условный прогон, но всего тестов 1400+. Получается, для каждого билда надо 2 таких прогона? Либо гоняются не все тесты, а лишь часть?
На ваш взгляд, стоит ли запускать для МРа все 1400+ ui-тестов, или можно высчитать, в каких именно фичах/модулях были правки, и запустить только те ui-тесты, которые проверяют затронутый функционал? Для unit-тестов такое сделать можно (смотрим на затронутые модули), для ui-тестов это выглядит куда сложнее
Нет ли большого оверхеда по времени из-за создания своего эмулятора под каждый тест? Пока эмуль запустится и выйдет на связь с adb, может пройти какое то время, даже если эмуль "прогретый" (с сохраненным снапшотом состояния).
Спасибо за статью! Интересен такой нюанс: как вы управляете правами доступа к /dev/kvm внутри контейнера с эмулятором?
Если правильно помню, прокинутый /dev/kvm залетает в докер-контейнер с id его владельца на хосте. При попытке запустить эмулятор от лица непривилегированного пользователя может не хватит прав на работу с KVM.
/dev/kvm доступен только при работе контейнера, при сборке самого докер-образа его еще нет, заранее права не выдать. А выдавать права во время работы контейнера в стиле `sudo chmod` тоже не хочется.
В целом можно, команда `emulator -no-accel` запустит эмулятор без аппаратного ускорения.
Эмилия, спасибо за статью. Кажется, что добиться того, чтобы 1400 ui-тестов нормально гонялись на каждом билде к МРу - это немалая работа. :)
Расскажите, пожалуйста, еще про облачную/CI часть.
3 потом по 250 - это 750 тестов за условный прогон, но всего тестов 1400+. Получается, для каждого билда надо 2 таких прогона? Либо гоняются не все тесты, а лишь часть?
На ваш взгляд, стоит ли запускать для МРа все 1400+ ui-тестов, или можно высчитать, в каких именно фичах/модулях были правки, и запустить только те ui-тесты, которые проверяют затронутый функционал? Для unit-тестов такое сделать можно (смотрим на затронутые модули), для ui-тестов это выглядит куда сложнее
Нет ли большого оверхеда по времени из-за создания своего эмулятора под каждый тест? Пока эмуль запустится и выйдет на связь с adb, может пройти какое то время, даже если эмуль "прогретый" (с сохраненным снапшотом состояния).