Это уже обвязка вокруг агент - мок-прокси, который мы написали перехватывает трафик и по правилам из теста (они формируются через умный парсер) подменяет ответы на запросы.
Интересно. А как это устроено? Парсер получает сценарий описанный натуральным языком и на основе него понимает какие ручки замокать и чем? Или тут пока нужен человек еще?
полноценный e2e сценарий от начала до конца не в коде.
Е2Е в плане мобилки - да, но в плане всей системы - с моками, без реальных походов в бэк, часть проблем можно не увидеть. А с реальными походами в бэк нестабильности куда больше(
Если что‑то пошло не так, например ожидаемый экран не появился, агент пытается скорректировать свои действия, опираясь на контекст и историю.
Как это выглядит на примере? "Скорректировать свои действия" можно трактовать по-разному, не сойдет ли агент с нужного сценария?
Это принципиально отличается от классических E2E‑тестов, где каждый шаг жестко привязан к конкретному элементу по ID или XPath. Агент оперирует визуальным и смысловым пониманием интерфейса, именно поэтому он устойчивее к изменениям UI.
Не обязательно привязываться к ID элементов в дереве вьюшек, можно искать по смысловым признакам (ищем красную кнопку с лейблом "купить" и хинтом "купи побыстрее", и нажимаем на нее), и такого поведения можно добиться без агента. Хотя, может, от платформы зависит.
Получается, основное нововведение в том, что агент на основе тест-кейса проходит этот сценарий без написания самого кода UI-теста? А как он подставляет моки запросов в таком случае? И можно ли на основе дейтвий агента сгенерить код через "Recording UI automation for testing" от Apple?
Спасибо за статью! Интересен такой нюанс: как вы управляете правами доступа к /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, может пройти какое то время, даже если эмуль "прогретый" (с сохраненным снапшотом состояния).
Интересно. А как это устроено? Парсер получает сценарий описанный натуральным языком и на основе него понимает какие ручки замокать и чем? Или тут пока нужен человек еще?
Е2Е в плане мобилки - да, но в плане всей системы - с моками, без реальных походов в бэк, часть проблем можно не увидеть. А с реальными походами в бэк нестабильности куда больше(
Как это выглядит на примере? "Скорректировать свои действия" можно трактовать по-разному, не сойдет ли агент с нужного сценария?
Не обязательно привязываться к ID элементов в дереве вьюшек, можно искать по смысловым признакам (ищем красную кнопку с лейблом "купить" и хинтом "купи побыстрее", и нажимаем на нее), и такого поведения можно добиться без агента. Хотя, может, от платформы зависит.
Получается, основное нововведение в том, что агент на основе тест-кейса проходит этот сценарий без написания самого кода UI-теста? А как он подставляет моки запросов в таком случае? И можно ли на основе дейтвий агента сгенерить код через "Recording UI automation for testing" от Apple?
Если в максе есть аудио и видео звонки, которые работают если приложение в фоне, то как минимум для них
Спасибо за статью! Интересен такой нюанс: как вы управляете правами доступа к /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, может пройти какое то время, даже если эмуль "прогретый" (с сохраненным снапшотом состояния).