Kaspresso научился сравнивать скриншоты: как автоматически ловить поломки в дизайне Android-приложений

Что появилось / что изменилось

Kaspresso — open source‑фреймворк «Лаборатории Касперского» для UI‑тестирования Android, который строится поверх Kakao, Espresso и UI Automator. В нём появилась новая возможность: визуальные тесты на основе сравнения скриншотов.

Теперь Kaspresso умеет:

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

Новая функция оформлена в отдельный базовый класс VisualTestCase и вспомогательное API runScreenshotTest. Поддерживаются обычные Android‑экраны, есть отдельная зависимость для Jetpack Compose и интеграция с Allure для репортинга.

Подключение минимальное: достаточно добавить mavenCentral в allprojects и несколько зависимостей в androidTestImplementation, включая:

• com.kaspersky.android-components:kaspresso:<latest_version>
• kaspresso-allure-support
• kaspresso-compose-support при работе с Compose.

Как это работает

Новый сценарий строится вокруг класса VisualTestCase. Это надстройка над обычным инструментальным тестом, в которую уже заложены:

• логика работы с файлами скриншотов;
• доступ к API сравнения изображений;
• интеграция со step‑логированием Kaspresso.

Типичный тест выглядит так:

1. Вы наследуетесь от VisualTestCase.
2. Выдаёте тесту права на работу с хранилищем через GrantPermissionRule. Для Android 33+ добавляете Manifest.permission.READ_MEDIA_IMAGES, для старых версий — только WRITE/READ_EXTERNAL_STORAGE. Пример из репозитория показывает условную выдачу прав через проверку Build.VERSION.SDK_INT.
3. Поднимаете нужную Activity через ActivityScenarioRule, например MainActivity.
4. Оборачиваете тестовый сценарий в runScreenshotTest { ... } — внутри Kaspresso уже решает, писать эталон или сравнивать с существующим.
5. Описываете экран в стиле PageObject через KScreen: выносите layoutId, viewClass и элементы (KButton, KTextView) с withId(...).
6. Строите сценарий пошагово через step("Open Simple Screen") { ... }: Kaspresso логирует шаги и при падении показывает, где именно всё остановилось.
7. В нужный момент вызываете API для съёмки и проверки скриншота (автор использует метод assertScreens): фреймворк делает снимок, сравнивает с эталонным и либо проходит тест, либо подсвечивает отличия и помечает его как проваленный.

Под капотом фреймворк работает как связка UI‑автоматизации (Kakao + Espresso + UI Automator) и файловых операций: он приводит экран в нужное состояние, делает системный скриншот, сохраняет в каталог, а потом побитово или по пикселям сверяет его с сохранённой версией и формирует артефакты с подсвеченными различиями.

Что это значит для вас

Для разработчиков Android:

• Можно автоматизировать регрессию по дизайну. Любое изменение отступов, размеров элементов или текста, которое раньше ловили «на глаз», теперь видно в отчётах автотестов.
• Легче проверять, что реальный интерфейс не разъехался после рефакторинга, обновления библиотек или смены темы.
• PageObject‑подход через KScreen делает тесты читаемыми: логика по описанию экрана отделена от сценария теста.

Для инженеров по тестированию:

• Визуальные проверки можно добавить к уже существующим Espresso‑тестам, не переписывая весь стек: Kaspresso и так опирается на знакомые инструменты.
• Пошаговое логирование через step помогает разбирать падения и собирать артефакты для багрепортов.
• Поддержка Allure упрощает построение наглядных отчётов, где дизайнер, PM и разработчик видят одинаковые скриншоты и подсветку отличий.

Для дизайнеров:

• Появляется более предсказуемый способ следить за соответствием макету: вы смотрите не только на пиксели в Figma, но и на эталонные скриншоты реального приложения.
• Можно быстрее находить, где «поехали» шрифты, интерлиньяж или размеры контролов.

Когда имеет смысл использовать:

• Регулярные регрессионные прогоны UI после релизов и крупных рефакторингов.
• Проекты с жёсткими гайдлайнами по визуалу, где важны пиксель‑перфект экраны.
• Команды, у которых уже есть культура инструментальных тестов под Android и желание добавить именно визуальный слой проверки.

Когда лучше смотреть в сторону других подходов:

• Если у вас только логические проверки (например, бизнес‑правила без сложного UI), то скриншотные тесты добавят нагрузку на инфраструктуру, а пользы будет немного.
• Если продукт ещё сильно меняет интерфейс каждую неделю, вы потратите много времени на обновление эталонных скриншотов.

Фреймворк распространяется как open source и ставится через стандартные репозитории Gradle, без обходных путей и VPN.

Место на рынке

Kaspresso опирается на стэк, который команды Android уже используют: Espresso, UI Automator и библиотеку Kakao. Новая функция сравнения скриншотов встроена прямо в этот стек, так что не нужно поднимать отдельный сервис или внешний тул для визуальных тестов.

По подходу Kaspresso ближе к классическим UI‑тестам на Espresso с добавленным визуальным слоем, чем к внешним «облачным» решениям для скриншотного тестирования. VisualTestCase, runScreenshotTest и PageObject через KScreen закрывают типичные потребности команды, которая хочет хранить эталонные скриншоты в проекте и запускать сравнение в своём CI.

Отдельных числовых сравнений с другими инструментами автор не приводит. Фокус именно на том, как подключить Kaspresso через Gradle, настроить права доступа под разные версии Android, описать экран и получить воспроизводимый визуальный тест внутри привычной инфраструктуры Android‑разработки.