Тестирование снимков экрана — очень эффективный способ проверить пользовательский интерфейс вашего приложения. Скриншотные тесты могут существовать в тестах компонентов, функций и приложений.
Вы можете использовать сторонние инструменты для создания как инструментальных, так и локальных скриншотов. Если вы используете Compose, вы можете использовать официальный инструмент тестирования Compose Preview Screenshot .
Определение
Скриншот-тесты делают снимок пользовательского интерфейса и сравнивают его с ранее утвержденным изображением, называемым «эталонным» или «золотым»:
Если изображения одинаковые, тест пройден. Если между ними есть различия, инструмент создает отчет:
В отчете у вас есть два возможных ответа:
- Осознайте, что в новом коде есть ошибка, и исправьте ее.
- Утвердите новый снимок экрана и замените эталонное изображение новым.
Тестирование снимков экрана имеет другой рабочий процесс, чем обычные тесты, поскольку неудачный тест не всегда означает наличие ошибки.
Преимущества
Преимущества или скриншот-тесты:
- Скриншот-тест выполняет несколько утверждений для каждого теста. Например, один тест может проверить цвета, поля, размеры и шрифты.
- Скриншот-тест гораздо проще написать, понять и поддерживать, чем эквивалентный поведенческий тест.
- Они особенно полезны при проверке и обнаружении регрессий на экранах разных размеров.
Недостатки
Однако скриншот-тесты могут иметь и недостатки:
- Работа с эталонными изображениями может быть затруднительной, поскольку в большом проекте могут использоваться тысячи PNG.
- На разных платформах (Linux, Max и Windows) снимки экрана немного различаются.
- Они медленнее, чем эквивалентные поведенческие тесты.
- Наличие большого количества тестов скриншотов может вызвать проблемы, например, когда одно изменение затрагивает тысячи скриншотов.
В следующих разделах представлены рекомендации по решению этих проблем.
Сведите скриншоты к минимуму
Вам следует свести к минимуму количество скриншотов-тестов, одновременно максимизируя обратную связь и охват регрессий.
Комбинации различных состояний пользовательского интерфейса могут очень быстро увеличить количество тестов. Ниже приведены некоторые способы проверки части пользовательского интерфейса вашего приложения:
- На разные темы
- Использование разных размеров шрифта
- Внутри разных размеров или границ экрана
Если вы сделаете это для каждого компонента, макета и экрана вашего приложения, вы получите тысячи файлов скриншотов, большинство из которых не дадут вам никакой дополнительной обратной связи.
Например, если вы хотите протестировать пользовательскую кнопку со светлой и темной темой и тремя размерами шрифта, вам не нужно создавать комбинации всех из них. Вместо этого вы можете выбрать только одну из тем. Это связано с тем, что реакция кнопки на длинные слова не влияет на тему.
Сохранение эталонных изображений
Эталонные (или золотые) изображения обычно представляют собой файлы PNG, которые можно зарегистрировать в системе управления версиями. Однако Git и большинство менеджеров контроля версий оптимизированы для текстовых файлов, а не для больших двоичных файлов.
У вас есть 3 варианта управления этими файлами:
- Продолжайте использовать git, но старайтесь минимизировать использование памяти.
- Используйте Git LFS .
- Используйте облачный сервис для управления скриншотами.
Различия платформ
Тесты снимков экрана основаны на низкоуровневых API-интерфейсах платформы для рисования определенных функций, таких как текст или тени, и платформы могут реализовывать их по-разному. Если вы разрабатываете на Mac и сохраняете новые снимки экрана, сделанные локально, вы можете увидеть неработающие тесты на машине Linux CI.
Есть 2 способа обойти проблему:
- Терпеть небольшие изменения
- Делать скриншоты на сервере
Терпеть небольшие изменения
Вы можете настроить большинство библиотек тестирования снимков экрана так, чтобы при сравнении двух снимков экрана были небольшие различия.
Есть два подхода к этому:
- Настройте допуск на основе процента измененных пикселей или процента от общей разницы в значениях пикселей.
- Используйте интеллектуальное различие — алгоритм, который сравнивает снимки экрана — для проверки структурного и семантического сходства вместо пикселей.
Недостатком этого подхода является то, что он может создавать ложные срабатывания и не обнаруживать ошибки, которые либо ниже порогового значения, либо ошибочно считаются достаточно похожими.
Делать скриншоты на сервере
Чтобы использовать компаратор скриншотов с точностью до пикселя, вы должны убедиться, что ваши тесты делают скриншоты в одинаковых условиях. Для этого вы можете использовать свою систему непрерывной интеграции (CI) или облачный сервис.
Например, вы можете создать шаг в рабочем процессе CI, который выполняет следующие действия:
- Запускает тесты снимков экрана (необходимы только в том случае, если не используется точное попиксельное сопоставление).
- Записывает новые снимки экрана, если предыдущий шаг не удался.
- Фиксирует новые файлы в ветку.
При таком подходе скриншоты-тесты никогда не завершаются неудачей в CI, но изменения вносятся автоматически. Таким образом, вы и проверяющие изменения смогут принять новые снимки экрана, объединив изменения.
Инструменты тестирования скриншотов
Рассмотрим следующие ключевые различия между доступными инструментами и библиотеками для тестирования скриншотов:
- Среда: локальные тесты, которые выполняются на хосте, или инструментированные тесты, которые выполняются на эмуляторе или устройстве.
- Механизм рендеринга. Решения для создания снимков экрана на стороне хоста могут использовать Layoutlib — механизм рендеринга Android Studio для предварительного просмотра — или Robolectric Native Graphics (RNG).
- Фреймворки на основе Layoutlib ориентированы на рендеринг статических компонентов, используя разные состояния для демонстрации разного поведения. Обычно их проще использовать.
- Фреймворки, интегрируемые с RNG, могут использовать все функции Robolectric, что позволяет проводить тесты в более широком масштабе.