Русский
Русский
English
Статистика
Реклама

На чем писать Android UI-тесты

Всем привет. Мы вAvokado Project продолжаем рассказывать проавтотестирование вAndroid. Эта статья обзор и сравнение существующих инструментов длянаписания UI-тестов.


Давайте начнем стого, что вспомним, как обычно выглядит процесс тестирования. Будем называть сущность, которая взаимодействует сприложением, клиентом. Длявзаимодействия сприложением клиенту обычно доступно несколько интерфейсов: API, REST API, CLI, GUI и т.д. И если, например, API используются клиентами-программами, тоGUI используется человеком.


Ожидания отповедения приложения описываются вспецификации. Задача тестирования проверить, что поведение приложения соответствует спецификации.



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


Вслучае ручного тестирования тестом является процесс прохождения тест-кейса человеком. Если этот процесс автоматизирован, то вместо человека сприложением взаимодействуют программные клиенты. Вэтом случае тестом также называется сам реализованный наязыке программирования тест-кейс.


Для реализации тестов и их автоматизированного запуска нам понадобится фреймворк тестирования (JUnit, Cucumber). Он включает всебя:


  • Набор функций для проверок в тестах ассерты (assertions).
  • Механизм создания фикстур дляшаринга данных междутестами. Вобщепринятом смысле фикстура фиксированное состояние окружения, накотором выполняются тесты.
  • Раннер длязапуска тестов.

В зону ответственности раннера всвою очередь входят:


  • подготовка окружения;
  • формирование набора тестов дляисполнения;
  • запуск тестов;
  • получение результатов выполнения тестов;
  • подготовка отчетов опрохождении тестов;
  • сбор статистики.

Несмотря на то, что сфреймворком поставляется также и раннер, существует возможность использования более совершенных сторонних раннеров. Тема раннеров, их особенностей вконтексте Android-тестирования, и выбора наиболее подходящего (Avito test runner, Marathon, Spoon, Fork) довольно обширна и заслуживает отдельной статьи, поэтому вернемся ксамим тестам.


Если API приложения доступен тесту напрямую, то дляGUI интерфейса нужны программные адаптеры драйверы.



Тесты, обращающиеся кGUI-драйверам, называются UI-тестами. Вотличие отunit-тестов, они выполняются нареальном девайсе или эмуляторе подуправлением соответствующей мобильной операционной системы.


GUI-драйверы являются наиболее сложным компонентом всего стека тестирования. Они решают базовые, низкоуровневые задачи. Когда вы даете GUI-драйверу (Espresso, UiAutomator) команду кликнуть накнопку, он обрабатывает ее, взаимодействует сприложением, и эта команда превращается вклик поэлементу.


Работа с API драйвера напрямую изтеста имеет ряд недостатков:


  • Функциональность драйвера ограничена: длятестов требуется дополнительное логирование, валидация данных, ожидания, повторы неудачных действий.
  • API драйвера не способствует написанию хорошо читаемого и легко поддерживаемого кода тестов.
  • Часто необходимо абстрагировать и унифицировать доступ сразу кнескольким драйверам.

Для устранений таких проблем используются обертки для драйверов, например, Kakao или Kaspresso. Эти обертки могут сильно различаться взависимости отрешаемых задач. Некоторые изних просто синтаксический сахар, другие же довольно толстая прослойка, выполняющая много сложной работы.



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


Драйверы


В Android-мире четыре популярных драйвера:


  • Espresso.
  • UiAutomator.
  • Robotium.
  • Selendroid.

Все они работают наAndroid Instrumentation Framework базовом API Android длявзаимодействия ссистемой. Самые популярные Espresso и UiAutomator. Они оба разрабатываются и поддерживаются компанией Google. Их без труда можно использовать одновременно впределах одного теста. Давайте рассмотрим их поближе.


UiAutomator



UiAutomator поставляется вместе сAndroid SDK начиная с16 версии API. Как GUI-драйвер он служит дляпоиска элементов интерфейса наэкране девайса и эмуляции различных действий: кликов, тачей, свайпов, ввода текста, проверок на видимость. Рекордер длязаписи тестов он не предоставляет, зато предоставляет утилиту дляпросмотра древовидной структуры экрана Ui Automator Viewer.


UiAutomator позволяет писать тесты помодели черного ящика (black-box). Он живет всобственном процессе и работает бездоступа кисходному коду приложения. Значит, тест сего использованием может взаимодействовать практически слюбыми приложениями, втом числе системными. Это открывает доступ кмножеству функций, например, становятся возможны:


  • набор номера и совершение звонка;
  • отправка и чтение смс;
  • взаимодействие с нотификациями;
  • управление настройками сети, геолокации;
  • снятие скриншотов.

Внутри UiAutomator реализован припомощи AccessibilityService, облегчающего работу сдевайсом людям сограниченными возможностями. Именно AccessibilityService знает, что вкаждый конкретный момент времени отрисовано наэкране и умеет сэтими элементами взаимодействовать. Дляэтого он строит виртуальное дерево компонентов просматриваемого экрана, вузлах которого находятся объекты AccessibilityNodeInfo. Эти узлы содержат метаинформацию осоответствующих им View: имя класса, координаты или отображаемый текст.



Каждая View реализует интерфейс AccessibilityEventSource и через Binder IPC оповещает системный AccessibilityManagerService окаждом действии, произведенном сней, например, оклике или смене фокуса. AccessibilityManagerService передает эти данные вкаждый активный наданный момент AccessibilityService и, вслучае теста, UiAutomator, которые обновляют свое виртуальное дерево компонентов. Потакой же схеме вобратную сторону передаются команды отAccessibilityServiceов и UiAutomatora котображаемым элементам интерфейса любого приложения всистеме. Если элемент интерфейса не является наследником View, то дляучастия втакой схеме длянего потребуется самостоятельно реализовать ряд методов.


Для более детального погружения вустройство работы UiAutomator рекомендуем ознакомиться сдокладом UI Automator deep diving.


Среди недостатков UiAutomator:


  • Сложный и универсальный механизм работы, затрагивающий Binder IPC, реализован неидеально. Длятого, чтобы выполнить то или иное действие UiAutomator ждет, пока приложение придет вконсистентное состояние. Он ожидает появления временного окна, втечение которого отсистемы не поступит никаких событий. Такое устройство приводит не только кнестабильности и низкой скорости исполнения команд, но часто даже кдлительным задержкам или кполной остановке теста.
  • Элементы интерфейса, не являющиеся наследниками View или отрисованные припомощи OpenGL или Unity, невидимы дляUiAutomatora, если разработчики заранее обэтом не побеспокоились. Поэтому, например, привзаимодействии смобильными играми уUiAutomatora могут возникать проблемы.

Таким образом, наиболее подходящим сценарием дляиспользования UiAutomator является не работа стестируемым продуктовым приложением, а взаимодействие состоронними или системными приложениями. Более подходящим инструментом дляработы спродуктовым приложением является Espresso.


Espresso



Это также официальный фреймворк дляUI-тестирования отGoogle, но тесты сего использованием работают уже помодели белого ящика (white-box). Espresso поддерживает Android API с10версии, хотя появился значительно позже. Предоставляет рекордер длязаписи тестов.


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


Espresso решает низкоуровневую задачу найти необходимый элемент наэкране позаданным параметрам (ViewMatcher), произвести сним действия (ViewAction) или выполнить проверки (ViewAssertion).



Синтаксис Espresso реализован наоснове фреймворка Hamcrest. Он построен наиспользовании иерархий вложенных матчеров сущностей, описывающих требования кобъекту, вслучае Espresso кэлементам интерфейса. Они используются призадании параметров поиска элемента наэкране, а также впроверках как описание свойств, которыми элемент должен обладать. Вложенность матчеров часто приводит ктому, что код тестов становится трудно читать и поддерживать.


@Testpublic void espressoTest() {    onView(allOf(allOf(withId(R.id.label_bf_hotelname),         isDescendantOfA(withId(R.id.custom_view_trip_review))),         isDescendantOfA(withId(R.id.contentView))))        .check(matches(            withEffectiveVisibility(Visibility.VISIBLE)        ));}

Стабильность и скорость тестов наEspresso обусловлены его внутренним устройством все команды Espresso выполняются втом же процессе, вкотором работает само тестируемое приложение. Действия и проверки преобразовываются и кладутся вочередь сообщений главного потока приложения. Выполняются они только когда приложение готово кэтому, то есть его главный поток находится всостоянии ожидания пользовательского ввода (idle).



Для того, чтобы убедиться вэтом, достаточно обратиться квнутренностям, например, метода check класса ViewInteraction. Передаваемый аргументом объект ViewAssertion вызовется наглавном потоке после ожидания idleа.


public ViewInteraction check(ViewAssertion viewAssertion) {    // (...)    runSynchronouslyOnUiThread(new Callable<Void>() {        @Override        public Void call() {            uiController.loopMainThreadUntilIdle();            // (...)            viewAssertion.check(...)        }    });}

Исходя извышесказанного можно выделить следующие недостатки Espresso:


  • Ему требуется доступ кисходному коду тестируемого приложения.
  • Он не видит ничего запределами процесса тестируемого приложения и не может взаимодействовать сдругими приложениями. Например, совершить звонок удастся, только если тестируемое приложение и есть звонилка. А вот кликнуть нанотификацию Espresso уже не сможет совсем. Скорее всего втестах придется прибегать кпомощи UiAutomator.
  • API Espresso построен таким образом, что не способствует написанию чистого и читаемого кода тестов. Обэтом придется придется заботиться отдельно.
  • У Espresso проблемы состабильностью приработе сосложными асинхронными интерфейсами и сосписками.

Если вы готовы самостоятельно искать решения этих проблем, или если они ввашем случае не играют роли, то Espresso это отличный инструмент, тесты будут быстрыми и стабильными.


Robotium и Selendroid


Robotium и Selendroid были довольно популярны допоявления Espresso и UiAutomator. Cейчас же их аудитория заметно сократилась, и развиваются они далеко не так активно. Оба инструмента могут работать только содним тестируемым приложением, не требуют доступа кисходному коду и поддерживают работу наэмуляторах и реальных устройствах.


Robotium может использоваться длятестирования приложений наAndroid API 8+, (поддержка работы сWebView доступна, однако, только сAPI 15), тесты длянего пишутся наJava. Также он предоставляет плагин Robotium Recorder дляIntelliJ IDEA и Android Studio.


Selendroid поддерживает ограниченный список версий API с10 по19. Он поддерживает протокол WebDriver, предоставляет утилиту Inspector дляпросмотра иерархии элементов и записи простых record-and-playback-тестов.


Если вы начинаете внедрять автотесты снуля, мы не видим веских причин использовать Robotium или Selendroid.


Robolectric


Несмотря нато, что Robolectric не вполне вписывается вописанную ранее структуру, его нельзя здесь не упомянуть. Он не является интеграционным тестовым фреймворком, сего помощью вы не сможете тестировать взаимодействие Android компонентов или писать UI-тесты. Однако Robolectric позволяет писать особые unit-тесты наоснове JUnit с использованием Android API.


Он мокирует часть Android SDK, предоставляя пользователю так называемые shadow-объекты. Robolectric берет насебя такие задачи, как inflate view, загрузка ресурсов, и множество других, которые имеют нативную С-реализацию наAndroid-девайсах. Поэтому Robolectric позволяет писать тесты, имеющие зависимости наAndroid, но запускать их не наэмуляторе или реальном девайсе, а надесктопной JVM. Это существенно ускоряет процесс сборки, запуска и выполнения тестов.


Обертки


Итак, сдрайверами и устройством наиболее популярных изних мы разобрались. Мы поняли, что все они решают низкоуровневые задачи: поиск элемента наэкране и выполнение сним какого-либо действия. Из-заэтого они предоставляют невыразительный API, которым неудобно пользоваться длярешения более высокоуровневых проблем. Например, ни один изних не предоставляет собственный механизм дляреализации повторов неудачных действий или логирования. Более того, часто существует необходимость работать втестах сразу снесколькими драйверами, например, сEspresso и UiAutomator.


На помощь приходят обертки. Именно кAPI оберток мы будем обращаться внаших тестах, и именно обертки предоставляют конечный арсенал приемов длянаших тестов.


Прежде, чем мы рассмотрим и сравним наиболее популярные обертки, выделим основные требования ктестам.


Стабильность. Общая беда всех инструментов дляUI-тестирования заключается втом, что ни один изних не позволяет реализовать абсолютно стабильные тесты. Тесты сиспользованием каждого изних будут флекать (от англ. чудной, чокнутый). То есть если вы запустите рабочий тест множество раз водинаковых условиях, то вряде случаев он может упасть. Причем причины таких падений могут быть совершенно непредсказуемыми. Избавиться отпадений полностью не удастся, ведь зачастую они вызваны нестабильностью окружения и среды запуска тестов.


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


Универсальность. Наш опыт привел нас кубежденности втом, что тесты должны быть реализованы помодели белого ящика, когда это возможно. Это позволяет добиться более высокой скорости и стабильности их исполнения посравнению сblack-box тестированием. Однако иногда это невозможно. Случается, что втестах требуется наличие функциональности, которую предоставляют только black-box решения, например, работы состоронними или системными приложениями. Поэтому обертка мечты должна уметь агрегировать подсвоим интерфейсом обращение кнескольким драйверам дляпредоставления как white-box, так и black-box фич.


Гибкость. Приложений нарынке великое множество, и каждое изних обладает своими особенностями. Разработчикам обертки вряд ли удастся заранее все предусмотреть и предоставить реализации всевозможных фичей, которые могут пригодиться пользователям. Поэтому обертка должна обладать точками расширения, быть гибкой и конфигурируемой, чтобы разработчики тестов могли безпроблем адаптировать ее длясвоих нужд.


Логи. Как мы уже выяснили, тесты неизбежно будут падать. Причем не только флекать: они будут устаревать, терять актуальность, и просто делать то, ради чего писались падать втех местах, где поведение приложения отличается отожидаемого, тем самым подсвечивая баги. А значит, нам придется много медитировать надупавшими тестами, расследовать все обстоятельства происшествий, выдвигать и проверять гипотезы, находить и исправлять проблемы втестах и всамом приложении. А дляэтого желательно не только наличие stacktraceа сошибкой, но и полноценных логов, чтобы после прохождения теста можно было понять, что происходило, и что сломалось.


Скриншоты. Одних логов бывает недостаточно. Очень часто возникает потребность увидеть, что реально отрендерилось наэкране намомент ошибки. Поэтому было бы очень кстати, если бы клогам прилагались скриншоты.


Доступ к adb. Часто изтестов бывает необходимо обратиться кadb: включить/выключить сеть, установить геолокацию, эмулировать работу сотпечатком пальца или работать сфайловой системой.


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


Теперь давайте сравним популярные обертки сэтими хотелками.


Appium



Appium это довольно популярный кросс-платформенный open source инструмент дляавтоматизации тестирования десктоп и мобильных приложений под Android и iOS. Архитектура Appium схожа сSelenium WebDriver, широко распространенным и ставшим стандартом вweb-тестировании. Кроссплатформенность достигается засчет использования разных драйверов дляразных платформ. Именно драйверы транслируют клиентский Appium-код вкоманды, непосредственно исполняемые наустройствах. Длянаписания тестов Appium предоставляет клиентские библиотеки сфиксированным API.



Стабильность. Как видно изрисунка, Appium является довольно громоздкой оберткой. Посути он представляет собой целый HTTP-сервер наNode.JS, который создает и обрабатывает WebDriver-сессии, где и происходит общение сконечным драйвером команд наустройстве. Такое сложное устройство хоть и позволяет абстрагироваться отплатформы, все же негативно сказывается как наскорости, так и настабильности тестов. Ксложным и громоздким механизмам, скрытым вдрайверах, Appium добавляет собственный оверхэд.


Универсальность. Appium умеет абстрагироваться не только отплатформы, но и отиспользуемого драйвера. В случае Android он спомощью своих адаптеров может транслировать команды как вчерный ящик UiAutomator, так снедавнего времени и вбелый ящик Espresso. Адаптер кдрайверу, который будет использоваться втесте, указывается, однако, приконфигурации передначалом теста. Это значит, что впределах одного теста работать и сEspresso и с UiAutomator не получится, придется выбирать.


Выразительный API. Длянаписания тестов Appium предоставляет клиентские библиотеки сфиксированным фасадным API, очень похожим наWebDriver. Appium не предлагает никакой архитектуры длятестов, все отдается наоткуп конечному разработчику.


Гибкость. Передначалом теста есть возможность задать конфигурацию, например, ОС намобильном устройстве, ее версию, тип девайса (реальный или эмулятор), таймаут ожидания ответа отAppium-сервера, язык, ориентацию, указать экран приложения, скоторого стартует тест. Также передначалом теста можно указать, какой драйвер будет использоваться. Однако гибкостью настроек и конфигурации все ограничивается функциональность драйвера не может быть расширена.


Логи. Не предоставляет инструмента длялогирования шагов, действий и проверок теста.


Скриншоты. Изкоробки готовой функции нет, хотя ее несложно добавить самостоятельно.


Доступ к adb. Благодаря своей клиент-серверной архитектуре уAppiumа нет проблем стем, чтобы посылать надевайс adb-команды. Это, бесспорно, является его плюсом.


Итог. Appium подкупает своей кроссплатформенностью. Он активно развивается Espresso драйвер был добавлен не так давно. Однако сложная клиент-серверная архитектура как плата закроссплатформенность не позволяет добиться высокой стабильности тестов, что вкупе сосложностью инициализации тестовых сессий сильно увеличивает длительность прохождения тест сьютов всравнении сконкурентами.


Также стоит отметить, что Appium это отдельная и зачастую чуждая Android-разработчикам технология. К тому же, если ввашем проекте используется Kotlin, втестах придется вернуться кJava. Из-заэтой чуждости Appium часто встречает неприятие состороны разработчиков. Это является негативным фактором, поскольку понашему опыту как раз разработчики должны драйвить процесс автотестирования. Подробнее вэтих докладах: Автотесты вАвито. Зачем они, как помогают, сколько стоят, Как начать писать автотесты и не сойти сума.


Kakao



Kakao простой и удобный Kotlin DSL дляEspresso. Он позволяет упростить код тестов наEspresso и повысить его читаемость.


Выразительный API. Посути Kakao это написанный завас boilerplate-код дляподдержки втестах следующих двух паттернов:


  • KView это Kakao-представление элемента интерфейса наэкране, скоторым происходит взаимодействие вовремя теста. Например, Kakao предоставляет такие готовые реализации, как KEditText, KButton и т.д. Пользователь может добавлять собственные.
  • Screen это реализация пришедшего измира веб-разработки паттерна PageObject. Screen это базовый класс, наоснове которого рекомендуется создавать собственные stateless-хранилища всех KView насоответствующих экранах приложения. Рекомендуется создавать отдельный Screen длякаждой активити, фрагмента или, например, диалога вашего приложения. Screenы описываются вотдельных файлах, таким образом работа пообнаружению элементов интерфейса наэкране отделяется отсамих тестов.

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


@Testpublic void espressoTest() {    onView(allOf(allOf(withId(R.id.label_bf_hotelname),        isDescendantOfA(withId(R.id.custom_view_trip_review))),        isDescendantOfA(withId(R.id.contentView))))        .check(matches(            withEffectiveVisibility(Visibility.VISIBLE)        ));}

получаем это:


object MainScreen : Screen<MainScreen>() {    val hotelName = KTextView { withId(R.id.label_bf_hotelname) }}@Testfun kakaoTest() {    MainScreen {         hotelName {             isVisible()         }     }}

Стабильность. Kakao это намного более тонкая обертка, нежели Appium, и поэтому вместе сосвоими бонусами она не вносит практически никакого оверхэда вваши тесты. Команды по-прежнему исполняются внутри главного потока тестируемого приложения. Все особенности Espresso втом, что касается стабильности тестов, также унаследованы возможны проблемы при работе сосложными асинхронными интерфейсами, списками и т.д.


Универсальность. Kakao оборачивает только Espresso, это исключительно белый ящик сдоступом кисходникам и слепотой запределами процесса тестируемого приложения.


Гибкость. Дляобеспечения расширяемости вKakao реализован механизм интерсепторов. Пользователь черезспециальное API может внедрять вызов собственного кода вмомент, когда выполняется та или иная Espresso-команда. Благодаря этому пользователь может самостоятельно добавить втесты, например, ожидания или повторы неудачных действий. Однако что-либо сделать вне процесса тестируемого приложения по-прежнему не удастся.


Логи. Логов изкоробки нет, как и вEspresso. Хотя можно добавить их самостоятельно припомощи интерсепторов.


Скриншоты. Механизма снятия скриншотов изкоробки также нет. Потребуется собственная реализация.


Доступ к adb. Отсутствует, как и уEspresso.


Итог. Таким образом, Kakao это удобный DSL дляупрощения написания и поддержки тестов наEspresso. Но помимо него длярешения многих бытовых задач вам необходимо будет использовать UiAutomator, чей API уже не такой выразительный. Скорее всего современем вам придется дописать множество собственных надстроек длярасширения функциональности, например, длялогирования и повторов.


Barista



Barista это объемная библиотека, содержащая большое количество полезных решений и приемов приработе сEspresso.


Выразительный API. Как и Kakao, эта библиотека построена поверх Espresso. Однако Barista скорее широкий набор приемов, которые можно выборочно использовать всвоих Espresso-тестах. Этот набор приемов включает всебя:


  • Удобные и лаконичные helper-методы длявзаимодействия сэлементами интерфейса, которые скрывают отнас Espresso вызовы. Например, дляобыкновенного клика покнопке вместо onView(withId(R.id.button)).perform(click()) наголом Espresso получаем простой метод clickOn(R.id.button). Или вместо множества строчек кода дляклика наэлемент списка получаем просто clickListItem(R.id.list, 4).
  • Расширенный Android-специфичный Assertions API.
  • Инструмент длямокирования результатов интентов, правда пока только для работы скамерой.
  • Инструмент дляработы сruntime permissionами.
  • Огромное количество test ruleов, например, дляперезапуска flaky-тестов или дляочистки послепрогона теста shared preferences, базы данных, или удаления файлов сустройства.

Также Barista умеет работать сNestedScrollView, вотличие отEspresso, и еще включает всебя множество других приятных фишек. Но никакого специального DSL библиотека не предоставляет, поэтому формирование архитектуры втестах остается запользователем.


Стабильность. Благодаря вышеупомянутому FlakyTestRule есть возможность перезапускать падающие тесты. Однако обычно эту задачу успешно решают раннеры. Ктому же вбиблиотеке отсутствует механизм ретраев дляотдельных действий и проверок, что позволило бы не перезапускать каждый раз весь тест целиком и экономить время.


Универсальность. Исключительно белый ящик из-заработы только поверх Espresso.


Гибкость. Расширять вэтой библиотеке посути нечего, можно только вдохновляться и выделять у себя впроекте подобные рабочие Espresso приемы. И ваша свобода ограничена только функциональностью Espresso.


Логи. Механизм для логирования шагов, действий и проверок втестах отсутствует.


Скриншоты. Механизм снятия скриншотов также отсутствует.


Доступ к adb. Отсутствует, как и уEspresso.


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


Kaspresso



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


Выразительный API. Создатели вдохновлялись наработками инженеров изАвито и красотой Kakao. Kaspresso расширяет лаконичный Kakao DSL он предоставляет собственный Kotlin DSL дляописания тестовых секций и шагов, внутри которых продолжает жить Kakao сосвоими Screenами и KView.


@RunWith(AndroidJUnit4::class)class OpenHomeScreenTest : TestCase() {    @Test    fun kaspressoTest() {        before { ... }        .after { ... }        .run {            step("1. Open Home screen") {                 MainScreen {                    openHomeScreenBtn.click()                }            }            step("2. Check Home title") {                 HomeScreen {                    title.isVisible()                }            }            step("3. Do some stuff") { ... }        }    }}

За Kaspresso API скрывается много работы длярешения основных задач, рано или поздно возникающих передразработчиком автотестов. Правильное использование фреймворка подталкивает пользователя киспользованию зарекомендовавших себя паттернов построения декларативных, поддерживаемых и стабильных тестов (см. How to write autotests).


Универсальность. Kaspresso как фреймворк-обертка агрегирует подсвоим API обращение и кEspresso и кUiAutomator. Таким образом, тесты сего использованием могут работать как внутри процесса тестируемого приложения, так и вне его, когда это необходимо. Например, если вовремя теста вам необходимо зайти встороннее приложение или кликнуть нанотификацию, сего помощью сделать это не составит проблемы. Kaspresso предоставляет Kautomator собственную Kakao-like обертку для работы сUiAutomator, что делает дляпользователя обращение кEspresso и кUiAutomator визуально неотличимым.


object KakaoScreen : Screen<KakaoScreen>() {    val title = KTextView { withText(R.string.title1) }    val btn = KButton { withId(R.id.button1) }}object KautomatorScreen : UiScreen<KautomatorScreen>() {    val title = UiTextView { withText(R.string.title2) }    val btn = UiButton { withId(pkgName, R.id.button2) }}@Testfun kaspressoTest() {    KakaoScreen {         title.isVisible()        btn.click()    }    KautomatorScreen {        title.isVisible()        btn.click()    }}

Для взаимодействия сдевайсом и операционной системой можно воспользоваться специальным фасадом device. Вот лишь неполный список того, что возможно сего помощью:


  • набор номера и совершение звонка;
  • отправка и чтение смс;
  • работа сфайловой системой;
  • управление настройками сети, языка, геолокации;
  • установка и удаление приложений вовремя теста;
  • снятие скриншотов;
  • смена ориентации девайса;
  • взаимодействие схардварными кнопками: back, home, recents.

Архитектура самого Kaspresso во многом строится наиспользовании паттерна интерсептор, что обеспечивает соответствие следующим четырем пунктам этого критерия.


Гибкость. Kaspresso предоставляет пользователю возможность конфигурации и расширения, позволяя внедрять кастомные реализации интерсепторов разных типов. Вы можете внедрять вызов собственного кода вответ наразличные события, например, накаждый вызов ViewAction или ViewAssertion, настарт, успешное окончание или падение шага вашего теста или всего теста целиком. Стоит отдельно подчеркнуть, что все параметры могут быть настроены передзапуском теста, ненужная функциональность может быть отключена, а недостающая добавлена (см. Configurator).


Стабильность. Kaspresso проникает всамые недра Espresso и UiAutomator и умеет повторять завалившиеся действия или проверки, закрывать всплывающие системные диалоги, автоматически доскраливать доэлемента внутри ScrollView, если это необходимо, что заметно повышает стабильность тестов. Вы можете воспользоваться готовыми реализациями интерсепторов или специальными helper-методами. Например, дляповтора неудачного клика покнопке заверните ваше действие вблок flakySafely:


MainScreen {    flakySafely {        btn.click()    }}

Логи. Доступны и поумолчанию используются готовые реализации интерсепторов, которые логируют необходимую информацию окаждых действии или проверке, стадии жизненного цикла шагов или всего теста.


Скриншоты. Также доступны реализации интерсепторов дляснятия скриншотов послекаждого шага и поокончанию всего теста. Этот механизм легко кастомизировать, и Kaspresso будет делать скриншоты именно тогда, когда это нужно пользователю. Также скриншот можно сделать просто изкода теста:


device.screenshots.take("MainScreen_step_1")

Также см. Localization autotests.


Доступ к adb. Еще одной не менее важной составляющей Kaspresso является AdbServer HTTP-сервер, который умеет выполнять запрашиваемые изтеста adb-команды. Он запускается нахосте, ккоторому подключены девайсы или эмуляторы, накоторых будут запускаться тесты. Вовремя запуска теста надевайсе происходит соединение ссервером, и далее сервер может выполнять запрашиваемые изтеста adb-команды длянужного девайса. AdbServer используется дляреализации большинства функций, доступных черезфасад device. Также внутри тестов вам доступно простое и удобное API длявызова необходимых adb-команд:


adbServer.performAdb("emu sms send +79111111111 $smsText")adbServer.perfromShell("rm -f $filePath")

Однако AdbServer опционален, его не обязательно запускать, если вваших тестах не требуется обращение кadb.


Какую обертку выбрать


Appium Kakao Barista Kaspresso
Выразительный API + +
Универсальность +
Гибкость + +
Стабильность +
Логи +
Скриншоты +
Доступ к adb + +
Изэтой таблицы ответ должен быть очевиден. Если вы только начинаете погружение в мир автотестирования, проще всего будет начинать вместе сKaspresso. Он решит за вас множество проблем, скоторыми вы непременно столкнетесь. Он предоставляет удобный API, включающий и расширяющий Kakao, под которым скрывается обращение и кEspresso, и кUiAutomator, и кAdbServer, что значительно расширяет ваши возможности. И, что не менее важно, он содержит специальные точки расширения, так что вы сможете добиться отнего необходимого поведения.
Источник: habr.com
К списку статей
Опубликовано: 04.09.2020 12:07:35
0

Сейчас читают

Комментариев (0)
Имя
Электронная почта

Блог компании авито

Разработка под android

Тестирование мобильных приложений

Android

Ui testing

Appium

Kakao

Barista

Kaspresso

Espresso

Uiautomator

Категории

Последние комментарии

  • Имя: Murshin
    13.06.2024 | 14:01
    Нейросеть-это мозг вселенной.Если к ней подключиться,то можно получить все знания,накопленные Вселенной,но этому препятствуют аннуннаки.Аннуннаки нас от неё отгородили,установив в головах барьер. Подр Подробнее..
  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru