Dev Easy Notes

Как работают 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

www.tgoop.com/dev_easy_notes/446

2.37K viewsedited  Jun 5 at 12:44

Как работают 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 эмуляторов.

BY Dev Easy Notes