Искать на сайте Unity

UNIFIED TEST RUNNER И АНАЛИЗ ТЕСТОВЫХ ДАННЫХ

Автор:

Yan Drugalya

7 октября 2015 г. через Технологии | 3 мин. читать

Охваченные темы

Is this article helpful for you?

Thank you for your feedback!

Привет! Меня зовут Ян, и последние два года я создавал инструменты разработки в Unity. Мы росли, росли и наши наборы тестов, а вместе с ними росло число неустойчивых тестов, медленных тестов и невоспроизводимых ошибок. В этом посте я расскажу, как мы с этим боремся, а чтобы вы лучше осознали, с какими сложностями мы имеем дело, сначала я объясню, как устроена наша среда автоматизации.

У нас в Unity много направлений тестирования (см. рисунок 1) и наборов тестов:

Тесты времени выполнения позволяют тестировать публичный API времени выполнения Unity на всех платформах, которые мы поддерживаем.
Интеграционные тесты предназначены для проверки того, что сложно проконтролировать тестами времени выполнения — они позволяют тестировать функциональность редактора Unity Editor и интеграцию с такими компонентами, как Cache Server и Bug Reporter.
«Родные» тесты C++ предназначены для непосредственного тестирования кода C++, минуя слой скриптинга.
Графические тесты контролируют функции визуализации, сравнивая полученные изображение с эталонными.
И многое другое (тесты производительности, загрузки, графический интерфейс 3D-визуализации и т.д.).

Рисунок 1. Направления тестирования в Unity

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

Чтобы упростить всю эту систему, около года назад мы начали работу над Unified Test Runner (UTR) — универсальным исполнителем тестов: единой точкой запуска всех тестов. UTR служит входом (см. рисунок 2) для всех исполнителей и направлений тестов. Благодаря этому любой пакет тестов теперь можно запустить из командной строки.

Рисунок 2. Unified Test Runner как входная точка для всех тестов

Figure 2. Unified Test Runner Facade — Рисунок 2. Unified Test Runner как входная точка для всех тестов

Все результаты тестов сохраняются на едином ресурсе, где они группируются согласно единым правилам. UTR также предоставляет другие возможности:

к тестам можно применять фильтры: -testfilter=TestName
для всех наборов тестов используются единые правила индикации хода тестирования

Изначально мы выполняли тестирование локально. Затем мы решили использовать Unified Test Runner в работе нашей системы сборки релизов Build Farm. Идея была в том, чтобы запускать одни и те же тесты с локальных компьютеров и при сборке релизов — если что-то шло не так, всегда можно было проверить тест локально.

Постепенно UTR стал точкой единого входа для всех тестов в Unity. И тогда мы решили использовать его еще для одной задачи — сбора данных о выполнении тестов с локальных компьютеров и из Build Farm. По окончании каждого теста UTR передает результаты в специальную веб-службу. Так появилось наше решение для анализа данных, которое называется Hoarder. Оно собирает данные о выполнении тестов, хранит их, предоставляет к ним доступ и отображает агрегированную статистику тестирования с возможностью «проваливаться» в результаты отдельных тестов (см. рисунок 3).

Рисунок 3. Агенты сборки релизов и пользователи загружают данные в веб-службу Hoarder, где их обрабатывает аналитическое приложение.

Figure 3. Build agents and humans submit data to Hoarder Web Service. Analytics application fetching it — Рисунок 3. Агенты сборки релизов и пользователи загружают данные в веб-службу Hoarder, где их обрабатывает аналитическое приложение.

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