В прошлой статье я рассказывал, что для ускорения проверки релизов мы используем Appium. Ниже расскажу, как мы настроили инфраструктуру, способную прогонять более 5 тысяч тестов в сутки на iOS и Android суммарно. Секрет прост — использовать Selenoid. Об этом и расскажу под катом.  В прошлом году на Хабре вышла статья по исследованию автотестов, в рамках которой мы приняли участие в опросе. Результаты опроса нас порадовали, поэтому мы решили написать статью, поделиться опытом с вами и получить советы. Материал решили разделить на две части: в первой части расскажем про Android, во второй — про iOS. Начнём с Android. Selenoid — популярный инструмент, который позволяет запускать браузеры и Android-эмуляторы в Docker контейнере и управлять ими. Подробнее можно прочитать в документации или в статьях на Хабре: раз, два и три. Для написания тестов на Appium мы используем: Kotlin; JUnit 5; Maven. Создаём конфиг browsers.json: В image указывается образ эмулятора. Ребята из aerokube подготовили готовые образы Android-эмуляторов. Их можно посмотреть тут или тут. Образы ничем не отличаются. Для примера выберем образ browsers/android:10.0. Образ надо заранее скачать: docker pull browsers/android:10.0, иначе тесты не запустятся: Следующим шагом запускаем Selenoid. Делаем напрямую через docker, есть возможность запуска через Configuration Manager. Работоспособность Selenoid можно проверить через ссылку в браузере http://localhost:4444: Указываем адрес Selenoid в Appium-тестах в драйвере: Дальше указываем ссылку на сборку в capabilities: Если нет возможности указать ссылку, можно указать путь до сборки: Где /builds/app.apk — путь внутри контейнера, где запускается эмулятор. Чтобы вариант работал, надо указать volumes в browsers.json: Где /home/username/app.apk — путь до сборки на хосте. Всё, мы почти настроили Selenoid и можем попробовать запустить тесты: Но, к сожалению, тесты не смогут запуститься. Идём разбираться. Первое, что надо сделать после неудачного запуска — посмотреть логи Selenoid: Видим статус SERVICE_STARTUP_FAILED. Идём в документацию и смотрим значение статуса: Ошибка ничего не говорит, нужно больше информации. Хорошо бы посмотреть логи контейнера. Так и сделаем — для этого включим логирование: Также включаем логи в capabilities: Запускаем тесты и смотрим логи через браузер http://localhost:4444/logs/:  Логи контейнера тоже ничего не говорят, потому что не видно логов Appium. Давайте попробуем их включить. Для этого посмотрим на скрипт entrypoint.sh: Чтобы включить логи Appium, надо передать в контейнер параметры VERBOSE=true и APPIUM_ARGS=--log-level debug: Чтобы включить дебажные логи Appium, необходимо передавать VERBOSE, а в этом случае включаются логи эмулятора и начинают заполнять «эфир». Но мы это исправили для будущих образов =)  Теперь достаточно передавать в контейнерAPPIUM_ARGS=-log-level debug  Уже чуть больше информации. По логам видно, что Appium не может найти наш элемент. Посмотрим, что происходит на экране эмулятора. Для этого надо запустить Selenoid UI: Переходим по ссылке http://0.0.0.0:8080 и открываем Selenoid UI: Не забудем включить в тестах VNC и видеозапись: В итоге команда запуска Selenoid выглядит так: После запуска тестов открываем Selenoid UI: А вот и видеозапись: Ура, мы нашли причину ошибки запуска. Идём дальше. Как оказалось, у образов Selenoid нету сервисов Google Play. Чтобы исправить это, надо самому собрать образ эмулятора. Ребята из aerokube подготовили для этого все необходимое: репозиторий с образами и документацию. Скачиваем репозиторий. Переходим в папку selenium.  Запускаем скрипт ./automate_android.sh и отвечаем на вопросы. В нашем случае это выглядит так: Когда увидел этот вопрос, то подумал, что это snapshot эмуляторов. Но если посмотреть код, то там вызывается скрипт, который нужен для установки APK приложений. По сути, это не даёт нам какого-либо выигрыша. Если говорить про ускорение запуска контейнера, мы уже используем snapshot эмуляторов, но об этом расскажем в других статьях. 4. После того, как образ соберётся, появится предложение запушить его в registry. Нам пока это не нужно, поэтому любезно откажем: Мы собрали сборку с сервисами Google Play. Не забываем поменять параметр image в browsers.json и перезапустить Selenoid. Попробуем ещё раз запустить тесты: А вот и видеозапись прогона: Что мы сделали: Настроили Selenoid для запуска Android-тестов. Научились смотреть логи и видеозаписи для поиска проблемы. Собрали свой образ эмулятора c сервисами Google Play. О чём хотелось бы рассказать ещё: О таймаутах Selenoid. Если у вас большое приложение, можно столкнуться с  проблемами, связанными с таймаутами. Как мы ускоряли запуск контейнера. На видеозаписи можно увидеть, что на запуск тратится примерно минута. Как мы пробовали запустить нативные тесты Android, написанные на Espresso, на Selenoid. Спойлер: это работает! А пока в следующей части расскажем, как мы масштабировали инфраструктуру и запускали тесты на iOS.