25.02.2019 09:42
tinkoff_qa 0 1700 Источник
Статья публикуется от имени Иванова Андрея и Батеевой Екатерины, neifmetus

Автоматизация мобильных приложений довольно молодая сфера: фреймворков много и многие проекты сталкиваются с проблемой выбора самого «быстрого, стабильного, простого в использовании». Также и мы около двух лет назад стояли перед выбором нового инструмента автоматизации тестирования Android приложений.
Все популярные инструменты так или иначе базировались на UIAutomator и Espresso, поэтому мы решили затестить их в чистом виде и сравнить с теми же Appium (самый популярный) и seeTest (использовался до этого, лучший среди платных на тот момент).

Из достоинств Appium можно выделить привычный многим WebDriver API, возможность использования большинства популярных языков и библиотек. Кроме этого, он широко используется во многих компаниях и позволяет писать тесты сразу под платформы iOS и Android. И, наконец, это бесплатное коробочное решение — что может быть лучше?

Так думали мы, пока не обнаружили следующие недостатки:
  • низкая стабильность Appium Server
  • нельзя взаимодействовать с публичными методами Activity (в 2018 году про создание backdoor в Appium рассказал в своей статье Николай Абалов из Badoo, прочитать можно здесь)
  • сильно уступает по скорости выполнения тестов Espresso

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

Итак, фреймворк был выбран, оставалось найти остальные компоненты:
  1. Runner — должен позволять запускать тесты параллельно и конфигурировать пулы устройств
  2. Reporter — должен предоставлять удобочитаемый отчет, которым мог бы пользоваться любой член команды


Инструменты


С runner’ом все обстояло хорошо, немного покопавшись на github, был выбран shazam/fork.
Он позволяет удобно конфигурировать пул устройств, прост в доработках, генерирует простенький html отчет. К каждому отчету прикладывается logcat, в случае падение теста stacktrace и видео. Запись видео работает некорректно, все видео длительностью 1 мин, иногда на видео записано по несколько тестов.

image

Отчеты fork’a были далеки от идеала, конечный пользователь не понимал, что происходит в тесте только по его названию, не имея тест-кейс под рукой. Хотелось иметь шаги с вложенными файлами, которые бы позволили структурировать отчет. Поиски репортера для instrumentation тестов выдали 2 варианта spoon и cucumber. Оба варианта были отброшены т.к куча скринов в случае spoon и bdd от cucumber не решали вопрос полностью…

Allure выглядел наиболее оптимальным вариантом решения задачи:
  • вложенность шагов, которая позволяет структурировать отчет
  • возможность записывать кастомные данные о тесте(скриншоты, видео, номер задачи, параметры теста)
  • лаконичный вид отчета

Но оставался один нюанс, Allure попросту не заводится на Android.

Allure-android


В связи с вышеописанным было принято решение написать библиотеку, которая бы совмещала в себе простоту и элегантность Kotlin, преимущества фреймворка Allure и могла работать на телефонах под управлением Android. Для того, чтобы подключить библиотеку, добавим зависимости к модулю, в котором находятся instrumentation тесты:
dependencies {
    androidTestImplementation "ru.tinkoff.allure:allure-android:$allureVersion@aar"
    androidTestImplementation "ru.tinkoff.allure:allure-common:$allureVersion"
    androidTestImplementation "ru.tinkoff.allure:allure-model:$allureVersion"
}


После настройки зависимостей, нам необходимо зарегистрировать AllureRunListener к классу отвечающему за запуск android тестов.

Сделать это можно тремя способами:
  1. Добавить в build.gradle 
    testInstrumentationRunner "ru.tinkoff.allure.android.AllureAndroidRunner"
  2. Добавить listener к аргументам в Runner onCreate(arguments: Bundle) 
    arguments.putCharSequence("listener", AllureAndroidListener::class.java.name)
  3. Напрямую наследоваться от AllureAndroidRunner


В основе отчетов Allure находится step – шаг, атомарное действие, которое производится во время теста. Аннотации фреймворка Allure Step и Parameter были заменены на прямой вызов функции step().
inline fun <T : Any?> step(description: String, vararg params: Parameter, block: () -> T): T

Эта функция не только заменяет сразу две аннотации, а также принимает лямбду, в которую следует обернуть тестовую логику. Например:
image

После запуска теста, на телефоне в папке /sdcard/allure-results появится отчеты в json формате подготовленные для Allure2. Вытащив результат, командой 
adb pull /sdcard/allure-results

сможем сгенерировать отчет 
allure generate


Из дополнительных возможностей, можно выделить:
  • возможность вкладывать шаги друг в друга
  • в любом месте можно вызывать deviceScreenshot(tag: String), чтобы сделать скриншот, который будет автоматически прикреплен к отчету в текущий step
  • FailshotRule() — junit4 Rule, сделает скриншот непосредственно перед падением


Это краткий обзор использования Allure на платформе Android. Решение allure-android доступно на GitHub, можно детально посмотреть и поучаствовать в развитии.

Комментарии (0)