TGViewer
Dev Easy Notes Dev Easy Notes @dev_easy_notes · 2.91K subscribers
Post #446 2.42K
Как работают UI-тесты на CI

Сразу обозначу: тема UI-тестов — это глубокая нора, и я сейчас буду говорить о ней только в контексте CI. Помимо этого, я не работал с UI-тестами на фронте, но, как мне кажется, там используется похожий принцип.

Допустим, у нас есть приложение на Android и iOS, и нам нужно организовать UI-тестирование на CI. Для Android необходимо запустить эмулятор, для iOS — симулятор.

Для Android мы берём базовый Docker-образ, например с Ubuntu, накатываем на него Android SDK и эмулятор. После этого мы можем использовать этот контейнер прямо в CI-джобе и запускать тесты.

Для iOS всё то же самое, но с одной оговоркой: из-за особенностей экосистемы Apple мы обязаны использовать Mac в качестве Runner-а. В нём уже должен быть предустановлен симулятор — никакой Docker тут не поможет.

На этом можно было бы и остановиться: такой подход будет работать, если у вас немного тестов и вы не психопаты, которые в UI-тестах ходят в реальный бэк. Но что делать, если у нас, скажем, 10 тысяч UI-тестов?

👉 Во-первых, одной джобой тут явно не обойтись.
👉 Во-вторых, если выполнять тесты последовательно на одном эмуляторе — вам никакого времени не хватит.

Именно поэтому почти в каждой крупной компании делают свою ферму устройств. Берём кластер серверов (кто-то хотел про кубер, вот тут он и выходит на сцену) и поднимаем множество контейнеров с Android-эмуляторами. Для iOS — используем кластер Mac-машин и на них запускаем симуляторы. Кроме того, можно подключить реальные устройства к сети и использовать уже их для тестов.

Теперь на CI-runner-е нам не нужно накатывать тяжёлый эмулятор. Мы просто разбиваем все наши тесты на группы. Каждая группа отправляется на свой эмулятор (или реальное устройство). После выполнения всех тестов мы собираем результаты со всех устройств, агрегируем их и формируем финальный отчёт.

Всю эту возню с разбивкой тестов, запуском, сбором результатов и т.д. берёт на себя специальный инструмент — Test Runner. Не путайте его с CI-runner-ом или JUnit Runner-ом — это совсем другое, про это писал тут.

В итоге в мобильной инфре мы получаем эдакий фрактал. Мы можем масштабировать как CI-runner-ы (чтобы обрабатывать больше джоб), так и количество устройств в ферме (чтобы джоба с тестами прогонялась значительно быстрее). Помимо этого мы можем идти и дальше, например разбивать все тесты на несколько CI-Job, каждая их которых будет использовать по 20-30 эмуляторов.
  • 👍 10
  • 🔥 3
  • ❤ 1
  • 🥰 1
More from @dev_easy_notes
  1. Sep 24, 2026На всякий случай напомню напомню, если такую хуйню видите, сразу в бан кидаете. Вы скорее…
  2. Aug 4, 2026Короче, поясню, я давно ничего не пишу, потому что заебался) возможно я скоро вернусь, как…
  3. Aug 4, 2026Post #596
  4. Apr 17, 2026Меня вот что еще дико бесит, через год я буду уже как 10 лет в индустрии и все равно, кажд…
  5. Apr 15, 2026video post
  6. Apr 9, 2026Как оценить работу модели? Часто вижу высказывания в стиле: вот новый клод стал тупее, или…
Threads Profile ViewerView any public Threads profile without an account.Open ThreadLook →Writing with AI? Make it sound human.Metric37 rewrites AI drafts so they read naturally. Free AI detector, 1,500 words free.Try Metric37 →