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

Меня зовут Олег Осипенко и эта статья является развитием моего доклада, посвященного опыту внедрения скриншот-тестирования, который я презентовал на прошедшей недавно в Екатеринбурге конференции DUMP. Отдельную часть доклада я посвятил разбору имеющихся библиотек, но, будучи ограничен временными рамками доклада, я не мог подробно остановиться на их особенностях. И сейчас я хотел бы восполнить это упущение. К тому же уже после доклада я нашел еще 2 новых библиотеки в дополнение к тем 5, что я упоминал в своем выступлении.

В этой статье я расскажу о следующих библиотеках:

• Facebook* Screenshot Testing Library

• Shot

• Paparazzi

• Dropshots

Facebook* Screenshot Testing Library

Библиотека от Facebook* появилась еще в 2015 году, когда она была представлена на конференции Droidcon NY. Благодаря этой библиотеке техника скриншот-тестирования заняла свое место в арсенале андроид-разработчиков.

Однако, на данный момент этот проект представляет интерес только с историографической точки зрения. Моя попытка интегрировать эту библиотеку на проекте завершилась неудачей как раз по той причине, что в Android слишком много всего изменилось с момента разработки - Android не стоит на месте, происходит постоянное обновление платформы, появляются новые инструменты и модели работы с данными на устройстве, разрешения и т.д. В этих условиях, любой Android-библиотеке просто для того, чтобы запускаться на новых версиях системы, требуется постоянная поддержка. Про библиотеку от Facebook этого сказать нельзя - её разработка практически остановилась, репозиторий забит открытыми issue и реквестами. К тому же для работы этой библиотеки требуются дополнительные зависимости, так как код для сравнения скриншотов написан на уже официально не поддерживаемом с 2020 года Python 2.

Shot

Развитием данного проекта является Shot, который использует библиотеку от Facebook* под капотом и решает все её проблемы, поскольку проект активно обновлялся вплоть до последнего времени. Интеграция в проект довольно проста: надо только подключить gradle-плагин:

// top-level build.gradle
buildscript {
    dependencies {
        classpath 'com.karumi:shot:<LATEST_RELEASE>'
    }
}

// app build.gradle
apply plugin: 'shot'

а также настроить тестовый раннер:

// app build.gradle
android {
    defaultConfig {
        testInstrumentationRunner "com.karumi.shot.ShotTestRunner"
    }
}

и в проекте появляется несколько новых задач по запуску и обслуживанию скриншот-тестов:

Shot tasks

----------

debugDownloadScreenshots - Retrieves the screenshots stored into the Android device where the tests were executed for the build Debug

debugExecuteScreenshotTests - Checks the user interface screenshot tests . If you execute this task using -Precord param the screenshot will be regenerated for the build Debug

debugRemoveScreenshotsAfter - Removes the screenshots recorded during the tests execution from the Android device where the tests were executed for the build Debug

debugRemoveScreenshotsBefore - Removes the screenshots recorded during the tests execution from the Android device where the tests were executed for the build Debug

executeScreenshotTests - Checks the user interface screenshot tests. If you execute this task using -Precord param the screenshot will be regenerated.

Сами тесты должны реализовать интерфейс ScreenshotTest, который предоставляет перегруженный метод compareScreenshot(). Стоит отметить, что библиотека поддерживает не только традиционные view-компоненты, но и Jetpack Compose:

class MyActivityTest: ScreenshotTest {
    @Test
    fun testActivityIsShownProperly() {
        val mainActivity = startMainActivity()
        compareScreenshot(activity)
    }
}

На выходе получаем вот такой отчет в HTML‑формате. Здесь оригинальный
референс, скриншот сделанный во время прогона теста и diff‑изображение,
помогающее лучше понять, в чем проблема.

Более подробно об использовании Shot для тестирования дизайн-системы приложения можно узнать из доклада Максима Теймурова на прошлом Mobius.

Однако, у Shot есть и свои недостатки. Во-первых, Shot для работы требуется доступ к adb. Для создания скриншотов нам требуется запустить тесты на устройстве, даже если мы используем эмулятор, эмулятор работает как отдельная виртуальная машина и у нас нет прямого доступа к его файловой системе. Здесь на помощь приходит adb - Android debug bridge, утилита из состава Android SDK, которая позволяет производить различные манипуляции с подключенным устройством, в том числе получать с него файлы: после прогона тестов Shot с помощью adb скачивает скриншоты и после этого запускает процесс сравнения изображений. Проблема с adb возникает в тот момент, когда над проектом работает несколько десятков человек и CI ежедневно выполняет сотни, если не тысячи проверок. В этот момент у вас может возникнуть непреодолимое желание как-то ускорить этот процесс путем различных оптимизаций, например с использованием отдельной девайс-фермы для запуска инструментальных тестов, такой как Firebase Test Lab. Но подобные фермы устройств, Firebase Test Lab, Aamazon Device Farm и другие, не дают клиентам доступа к adb, что исключает возможность использования Shot. Единственный выход из этой ситуации - это использование Shot только для верификации скриншотов:

shot {
    runInstrumentation = false
}

В этом случае мы можем запустить инструментальные тесты на Firebase, после этого скачать скриншоты из консоли и запустить их верификацию в Shot.

К тому же Shot требует идентичных настроек эмулятора на машинах, где предполагается выполнение скриншот-тестов, — нужно, чтобы везде использовалась одна и та же модель девайса, с одинаковой плотностью пикселей и т.п. На результат влияет даже разрядность образа эмулятора. Например, использование образа x86_64 вместо x86 приводило к получению отличающихся изображений. Причем отличались они не визуально, а на уровне байтов. Например вот так:

И это еще одно слабое место Shot - механизм сравнения изображений. Его алгоритм предельно наивен - он просто проходил по байтам двух изображений и сравнивал их на идентичность. Shot предоставляет дополнительную настройку tolerance - допустимый процент отличающихся пикселей. Но эта настройка слишком грубая: для того, чтобы нейтрализовать эффект из примера выше, tolerance нужно было бы установить на 10-15%, что само по себе бессмысленно - как мы можем говорить о похожести двух изображений, у которых могут отличаться 15% пикселей?! При таком большом значении tolerance легко пропустить настоящую регрессию.

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

Paparazzi

Властелины open source из компании Square, библиотеками которых пользуется каждый android разработчик, не прошли мимо скриншот-тестирования, создав новый проект под названием Paparazzi. В отличие от упомянутых выше библиотек Paparazzi не требуется подключение к Android-устройству для создания скриншотов. Вместо этого визуализация компонентов выполняется с использованием LayoutLib — движка рендеринга из Android Studio. Благодаря этому достигается высокая скорость выполнения тестов так как все тесты выполняются на JVM.

Для интеграции Paparazzi нам надо подключить к проекту плагин:

// top-level build.gradle
buildscript {
  repositories {
    mavenCentral()
    google()
  }

  dependencies {
    classpath 'app.cash.paparazzi:paparazzi-gradle-plugin:1.2.0'
  }
}

И применить его в модуле: apply plugin: 'app.cash.paparazzi'. Так как Paparazzi для выполнения тестов парсит ресурсы приложения, его использование возможно только в library-модулях — в модуле application ресурсы представлены уже в бинарном формате, работать с которым библиотека не в состоянии.

Сами тесты создаются в папке src/test и выглядят следующим образом:

class PaparazziScreenshotTest {
    @get:Rule
    val paparazzi = Paparazzi(
        deviceConfig = DeviceConfig.PIXEL_2,
        theme = "android:Theme.Material.Light.NoActionBar"
    )

    @Test
    fun testXml() {
        val view = paparazzi.inflate<ConstraintLayout>(R.layout.xml_layout_sample)
        paparazzi.snapshot(view)
    }

    @Test
    fun testCompose() {
        paparazzi.snapshot {
            SampleComposeContent()
        }
    }

    @Test
    fun testGif() {
        val view = paparazzi.inflate<ConstraintLayout>(R.layout.xml_layout_sample)
        paparazzi.gif(view)
    }
}

Paparazzi поддерживает тестирование как legacy-верстки в XML формате, так макетов, сверстанных с помощью Jetpack Compose и в одном тестовом классе можно комбинировать оба способа. Конфигурация рендеринга выполняется с использованием объекта Paparazzi, позволяющего настроить различные параметры отображения - модель устройства, тема приложения, отображение/скрытие клавиатуры и другие. Кроме того, у Paparazzi есть метод gif(), с помощью которого мы получим набор фреймов, что удобно для тестирования анимаций:

fun gif(
  view: View,
  name: String? = null,
  start: Long = 0L,
  end: Long = 500L,
  fps: Int = 30
)

К сожалению, данный метод поддерживает только макеты в XML.

После применения плагина Paparazzi в проекте появляются два новых Gradle-таска - для создания и верификации скриншотов. В случае возникновения регрессии Paparazzi создаст diff-изображение:

Однако Paparazzi при этом не лишен недостатков. Поскольку Paparazzi использует LayoutLib, его разработчикам требуется какое-то время на интеграцию новой версии LayoutLib из Android Studio в момент появления новой версии Android SDK. Таким образом всегда будет существовать определенный временной лаг между выходом новой версии Android SDK и появлением его поддержки в Paparazzi. По этой же причине Paparazzi очень легко ломается при обновлении Android Gradle Plugin, а также Jetpack Compose. Помимо этого Paparazzi закономерно наследует все баги, которые могут присутствовать в LayoutLib, а также его ограничения — например, если мы используем верстку на XML, мы не можем протестировать скриншот-тестами весь экран сборе, в том случае , если он он сверстан с применением adapter-view, таких как RecyclerView - на скриншоте мы увидим только RecyclerView, поскольку заполнение его элементами происходит уже во время выполнения приложения при подключении к нему адаптера. Также Paparazzi не поддерживает создание скриншотов из Activity и Fragment. Дополнительно стоит отметить свидетельства того, что результаты рендеринга с использованием LayoutLib могут отличаться на различных операционных системах, что будет приводить к падению скриншот-тестов.

Dropshots

Dropshots, еще одна библиотека для скриншот-тестирования ломает сложившуюся схему скриншот-тестирования, когда прогон инструментальных тестов используется для создания скриншотов, а затем запускается их сравнение с образцом. Вместо этого сравнение полученных скриншотов выполняется непосредственно во время выполнения инструментальных тестов. Благодаря этому скриншот-тесты можно запустить кнопкой пуск непосредственно из IDE (при использовании других библиотек необходимо запускать специальный Gradle-таск). Достигается это при помощи выполнения верификации непосредственно на устройстве.

Интеграция Dropshots в проект, наверное, самая простая. Для этого как обычно требуется подключить плагин:

// top-level build.gradle
buildscript {
  repositories {
    mavenCentral()
  }

  dependencies {
    classpath "com.dropbox.dropshots:dropshots-gradle-plugin:0.4.0"
  }
}

// build.gradle in the module
apply plugin: "com.dropbox.dropshots"

После этого можно написать новые, либо использовать уже имеющиеся инструментальные тесты - для того, чтобы превратить их в скриншот-тесты всего только нужно добавить вызов ассертов для скриншотов:

@RunWith(AndroidJUnit4ClassRunner::class)
class DropshotsSampleTest {
    @gett:Rule
    val activityRule = ActivityScenarioRule(MainActivity::class.java)

    @get:Rule
    val dropshots = Dropshots()

    @Test
    fun testDropshots() {
        activityRule.scenario.onActivity {
            dropshots.assertSnapshot(it)
        }
    }
}

После этого можно запустить тесты при помощи стандартной задачи Gradle connectedAndroidTest, либо нажатием на кнопку пуск в Android Studio. После этого образцы скриншотов будут загружены на девайс, затем на девайсе будут выполнены инструментальные тесты, во время которых будет сделан новый скриншот, запущено его сравнение с образцом и создано diff-изображение в случае возникновения каких-либо ошибок:

Однако, данный подход наряду с неочевидными преимуществами несет и недостатки: поскольку верификация выполняется на устройстве, время выполнения тестов увеличивается прямо пропорционально размеру изображения. Хотя референсы скриншотов упаковываются в тестовый apk и поэтому уже доступны локально на том устройстве, где выполняются тесты, получение дифф-изображения с устройства происходит с использованием adb, что опять же ограничивает сценарии возможного использования. К примеру, в отличие от Shot, Dropshots возможно использовать в связке с Firebase Test Lab, но в случае возникновения регрессии скачать дифф-изображение будет невозможно, поскольку эта операция производится через adb. Алгоритм верификации, используемый в Dropshots также не отличается особой изощренностью - в наличии два встроенных алгоритма: CountValidator и ThresholdValidator. Первый позволяет указать допустимое количество отличающихся пикселей в абсолютном выражении, а второй - их процент. Тем не менее, стоит отметить, что разработчики Dropshots немного позаботились об архитектуре своей библиотеки и оставили возможность использования пользовательских валидаторов, что позволяет реализовать более продвинутый алгоритм сравнения:

@get:Rule
val dropshots = Dropshots(
    resultValidator = MyCunnyScreenshotValidator()
)

В следующей части мы рассмотрим еще три библиотеки:

• Roborazzi

• Testify

• Kotlin Snapshot Testing

*Принадлежит meta, признанной в РФ экстремистской организацией.