Графические тесты: последний рубеж автоматизированного тестирования

Мы предусмотрели множество автоматических тестов. В Unity есть встроенные юнит-тесты, интеграционные тесты, системные тесты, которые работают и в редакторе, и в игровом режиме. И, наконец, у нас появились тесты графики. Такие тесты позволяют визуализировать сцену с использованием или без использования конкретных графических возможностей, сделать сборку этой сцены, запустить ее на всех поддерживаемых устройствах, а также сохранить кадр в виде изображения.

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

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

Работа с графическими тестами, по сравнению с обычными, осложняется их непостоянством. Визуализация на разных платформах, моделях устройств и видеокартах дает разные результаты, поэтому для получения однородных результатов в графических тестах мы проводим их на тестовой ферме, что обеспечивает постоянство аппаратной базы. Это усложняет процесс обновления и добавления новых тестов, поскольку разработчику необходимо:

1. Изменить код, обновить удаленный репозиторий.
2. Запустить графические тесты на всех соответствующих устройствах.
3. Подождать завершения тестов и получения неудачных результатов.
4. Загрузить эталонные изображения для проваленных тестов каждой сборки.
5. Сравнить каждое эталонное изображение с результатом, чтобы убедиться, что все получившиеся изменения были ожидаемыми.
6. В случае необходимости скопировать все новые изображения в репозиторий графических тестов.
7. Внести правки и обновить удаленный репозиторий графических тестов.
8. Заново запустить графические тесты.

Этот процесс может быть очень затратным по времени, поэтому в помощь разработчикам мы создали небольшое приложение Polymer на основе ASP.NET Core, которое получает информацию от Hoarder, системы статистики по сборкам, и находит все данные по графическим тестам для конкретных правок. Затем приложение загружает артефакты графических тестов по каждой сборке и выводит результаты на одной странице.

Разработчик видит проваленные тесты и может сравнить результаты с эталонными образами, а также визуализацией отличий. Тем не менее не всем и не всегда удается сразу заметить разницу между изображениями, как в примере ниже:

Именно поэтому приложение дает возможность разработчику переключаться между тестовым и эталонным изображениями, а также при необходимости просматривать разностное, чтобы быстро понять, в чем заключаются отличия. Это очень помогает, поскольку разницу между изображениями часто можно увидеть только при переключении между ними.

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

Учитывая, что в данной системе хранится информация о 13 700 графических тестах для 33 конфигураций сборок, и репозиторий графики обновляется ежедневно, этот инструмент упрощает жизнь разработчика и снижает объем ручной работы при проведении графических тестов.