Добавьте этот удобный инструмент в свой арсенал
Вы когда-нибудь задавались вопросом, как протестировать внешний интерфейс приложения? В этой статье мы подробно расскажем о визуальном тестировании, которое противопоставляется поведенческому тестированию. Можно ли автоматически проверять визуальное представление? Разве для этого не нужен человек?
Да, это возможно и полностью автоматизировано! Он уловит все визуальные регрессии и предоставит дополнительные преимущества, такие как демонстрация для новых членов команды.
Давайте посмотрим, какую регрессию он ловит.
Математически это неверно, но хорошо отображается. Поведенческий тест может предотвратить такую ошибку. Например, если вы используете JavaScript, вы можете написать тест, подобный приведенному ниже.
Теперь давайте посмотрим на визуальную регрессию.
В этом случае знак равенства плохо повернут. Это визуальная регрессия, которая могла быть вызвана модификацией, не имеющей четкого масштаба.
Давайте посмотрим, как это предотвратить.
Тестирование моментальных снимков
Визуальное тестирование повторно использует хорошо известную технику — тестирование моментальных снимков, также называемую золотым мастером.
Эта техника состоит из нескольких упорядоченных шагов:
- Снимок текущего состояния, которое будет эталоном
- Изменение кода
- Снимок нового состояния
- Сравнение эталонного состояния с новым состоянием
- Принятие изменений только в том случае, если разница соответствует ожидаемой.
Тестирование моментальных снимков может выполняться с использованием различных методов. Например, веб-разработчики могут сделать снимок DOM, чтобы увидеть влияние кода. Если вы хотите узнать больше об этой теме, я предлагаю прочитать Документацию Jest.
Визуальное тестирование визуализирует код и делает снимок экрана. Это особый случай тестирования моментальных снимков, при котором состояние сохраняется в виде изображения.
Давайте посмотрим, как автоматически сделать снимок экрана пользовательского интерфейса, чтобы определить будущие визуальные регрессии.
Рендеринг
Независимо от технологии интерфейса всегда есть движок, отвечающий за рендеринг. Он примет код в качестве входных данных и создаст визуальное представление в качестве вывода.
Для веб-разработки движок — это браузер. Он интерпретирует HTML, CSS и JS для рисования визуального элемента.
Если вы используете Flutter, рендеринг будет более сложным, потому что вы ориентируетесь на разные платформы. Как следствие, рендеринг разделен на две основные части. Универсальный движок написан на C/C++, а часть для встраивания содержит специфичные для платформы вещи. Для получения дополнительной информации вы можете прочитать эту документацию.
Идея визуального тестирования заключается в вызове механизма рендеринга через API и сохранении визуального элемента в виде изображения.
У некоторых интерфейсных технологий есть инструменты, которые вызывают у нас API. Например, Flutter предоставляет встроенную функцию, которая позволяет нам писать визуальный тест (также известный как золотой тест). При выполнении теста Flutter будет называть себя движком рендеринга.
Для веб-разработки нет встроенной функции, как во Flutter. На самом деле существует несколько браузеров, поэтому существует несколько методов рендеринга. Самый простой способ сделать это — использовать Selenium в качестве моста с вашим браузером. Он предоставит стандартный API для создания скриншота отображаемой страницы.
Теперь, когда вы знаете, как автоматически преобразовать визуализированный код в изображение, давайте посмотрим, как сравнить два изображения, чтобы найти различия.
Сравнение изображений
Референс и новое изображение имеют одинаковые размеры, потому что мы сделали их одним и тем же инструментом. Как следствие, мы можем использовать простой подход. Изображение можно рассматривать как двумерный массив байтов. Мы перебираем каждый бит и сравниваем их один за другим. Когда байты отличаются, мы помечаем текущую позицию.
Теперь вы знаете основные концепции визуального тестирования: создание снимков, рендеринг и сравнение изображений. Поговорим о главном.
Отображение несоответствий
Один и тот же код может создавать разные визуальные эффекты. Например, веб-приложение выглядит по-разному в зависимости от браузера. Даже если вы используете один и тот же движок, вы можете получить разные результаты. Это можно объяснить несколькими причинами. Вы можете использовать тот же движок, но другую версию, иметь предустановленные политики или использовать другую операционную систему (подробнее о Отрисовке шрифтов).
Эти небольшие несоответствия ужасны для командной работы. Тесты могут пройти для одного члена команды, но не пройти для другого. В таком случае доверять своим тестам нельзя, они бесполезны.
Решение состоит в том, чтобы принять различия на основе порога. Например, вы можете установить порог, который допускает отклонение от эталона только на 1%. Поиск правильного порога является экспериментальным. Чем выше порог, тем меньше вы поймаете регрессии, и чем он меньше, тем чаще тесты терпят неудачу из-за несоответствий. Вот почему я рекомендую рассматривать это решение как последнее средство.
Чтобы решить эту проблему, команда Flutter нашла интересное решение. Вы можете визуализировать свой код Flutter с помощью цветных квадратов вместо текстовых блоков. Это позволяет иметь одинаковый рендеринг на каждой платформе. Этот трюк возможен, потому что все платформы используют один и тот же движок рендеринга.
Если вы занимаетесь веб-разработкой, простое решение — использовать SaaS, например Chromatic, который будет делать скриншоты на той же платформе.
Наконец, вы можете воспользоваться преимуществами виртуализации самостоятельно, используя докер. Вам нужно будет использовать образ докера, содержащий движок, который отображает приложение.
Теперь, когда вы знаете, как устранить несоответствия рендеринга, давайте поговорим о дополнительных преимуществах визуального тестирования.
Дополнительные преимущества
Если вы практикуете проверку кода, как рецензент, вы сможете увидеть визуальное представление, создаваемое кодом. Кроме того, большинство платформ Git предоставляют инструменты для проверки различий между изображениями, поэтому вы сможете добавлять комментарии к изображениям, когда заметите подозрительное изменение.
Кроме того, у вас будет витрина вашего приложения. Это интересно для адаптации новых членов команды.
И последнее, но не менее важное: вы сможете увидеть визуальные изменения с течением времени. Это удобно, когда вы ищете, почему или когда что-то изменилось.
Ограничения
Ранее мы говорили о проблемах с рендерингом, однако существуют и другие ограничения.
Вы не можете тестировать анимацию с помощью визуального тестирования. Все упомянутые доступные инструменты заморозят вашу анимацию перед тем, как делать снимки экрана. Поэтому, если вы внесете изменения в анимацию, вас не поддержат.
Визуальные тесты медленнее классических модульных тестов. Они находятся в порядке секунды, а визуальные тесты - в порядке миллисекунды. Как следствие, ваш цикл обратной связи будет медленнее.
Заключение
Не поймите меня неправильно, визуальное тестирование — это не панацея. Он не заменяет другие методы тестирования, такие как тестирование поведения. Вы можете увидеть его как еще один инструмент в вашем наборе инструментов. Кроме того, у него есть некоторые ограничения, о которых вам нужно знать, например, несоответствия рендеринга.
Вы убеждены и хотите попробовать визуальное тестирование на своем проекте? Вскоре я выпущу практическое руководство для веб-разработчиков. Вы можете следить за мной для получения дополнительных статей такого рода.
Наконец, если вы практикуете TDD со своими поведенческими тестами, вы можете сделать то же самое со своими визуальными тестами. Это называется Visual Testing Driven Development (VTDD). Для получения дополнительной информации ознакомьтесь с этой Хроматической статьей.
