Мы переехали на ARM-архитектуру и наши Appium UI‑тесты стали пробегать в три раза быстрее. И это выгоднее, чем закупать в серверную классические Xeon'ы на X86!

А вдруг вы тоже хотите? Взвесить все «за» и «против» поможет эта статья, а бонусом — расскажу, куда можно дальше развить вашу новую тестовую инфраструктуру. Например, в ферму управления эмуляторами и девайсами.

Планируете внедрить или уже используете Appium-тесты для Android и задумываетесь о многопоточности? У нас есть для вас полный гайд, как реализовать это с помощью Selenoid – предварительно немного взбодрив образы для поддержки последних версий Android, и при этом сделав тестовую инфраструктуру стабильной, как молоток.

Всем привет!

В этой статье я бы хотел поделиться инструментом, который мы в Okko используем для UI-автотестов для клиентских приложений платформы Android. 

Обычно, когда в компаниях начинают задумываться о UI-тестах, первой вехой такой автоматизации являются чистые e2e-тесты. Это уже хороший результат, но, к сожалению, как только наше покрытие начинает выходить за рамки того, что можно сделать только через клиент, начинаются большие проблемы.

Также по мере расширения покрытия мы начинаем сталкиваться с проблемой времени выполнения тестов, которое может легко составлять и несколько часов, поскольку для каждого кейса мы должны заново прокликивать на клиенте все предусловия для какой-либо из проверок.

И соответственно, чем больше мы этим занимаемся, тем выше вероятность падения UI-тестов, поскольку в идеальном мире взаимодействия с клиентом должно быть ровно столько, сколько необходимо для выполнения теста, а у нас же получается всё наоборот. Поэтому после того, как такие тесты уже написаны, все начинают задумываться, а не начать ли применять к фронтовым тестам что-нибудь из бэкенда. Мы столкнулись с этой же проблемой. 

В статье я расскажу, как можно выйти из этого положения, причем данный опыт можно применить и превентивно, еще до того, как будут написаны ваши первые тесты.