Ян Другал занимается созданием инструментов разработки в Unity уже 2 года.
За последнее время его команда значительно выросла, а вместе с ней и наборы тестов, количество нестабильных, медленных тестов и невоспроизводимых ошибок.
Публикуем перевод статьи о том, как Ян и его команда решают эти проблемы.
В Unity есть множество областей тестирования (рис.
1) и наборов тестов: • Тесты на время выполнения позволяют тестировать общедоступный API среды выполнения Unity. на всех поддерживаемых платформах.
• Интеграционные тесты охватывают вещи, которые легко пропустить при тестировании во время выполнения, например функциональность редактора Unity или интеграцию с такими компонентами, как Cache Server и Bug Reporter. • Собственные тесты C++ предназначены для непосредственного тестирования кода C++ без использования сценариев.
• Графические тесты отвечают за функции рендеринга и позволяют сравнивать полученные изображения с эталонными.
• И многое другое (тесты производительности, загрузки, IMGUI и т.д.).
Рисунок 1. Направления тестирования в Unity
На верхнем уровне тесты сгруппированы по нескольким направлениям.
Дальнейшее деление зависит от платформы, частоты, времени выполнения и других критериев.
Эта структура дает нам огромное количество контрольных точек.
Но о них мы поговорим позже.
Чтобы упростить эту систему, около года назад мы начали разработку универсального средства запуска тестов — Unified Test Runner (UTR).
По сути, это единая точка входа (рис.
2), обеспечивающая универсальный интерфейс для всех исполнителей и тестовых площадок.
Таким образом, любой набор тестов можно запустить прямо из командной строки.
Рисунок 2. Unified Test Runner как точка входа для всех тестов
Все артефакты тестирования сохраняются в одном месте и группируются по общим правилам.
Кроме того, UTR предоставляет и другие возможности: • ко всем тестам можно применять фильтры: testfilter=TestName; • Для всех комплектов создаются одни и те же отчеты о ходе тестирования.
Первоначально мы использовали UTR для локальных тестов, но затем решили применить его и к нашей среде сборки.
Идея заключалась в том, чтобы запускать одни и те же тесты с локальных компьютеров и при сборке релизов.
Другими словами, чтобы в случае возникновения ошибки ее можно было воссоздать локально.
Постепенно UTR превратился в единую точку входа для всех тестов в Unity. И тогда мы решили использовать его еще для одной задачи – сбор тестовых данных с локальных компьютеров и из среды сборки.
По окончании каждого теста UTR передает результаты специальному веб-сервису.
Так родилось наше решение для анализа тестовых данных под названием Hoarder. Его задача — собрать данные о выполнении тестов, сохранить их, предоставить к ним доступ и отобразить совокупную статистику тестирования с возможностью углубленного анализа результатов отдельных тестов (рис.
3).
Рис.
3. Агенты сборки и пользователи загружают данные в веб-сервис Hoarder, где они обрабатываются аналитическим приложением.
Обрабатывая данные, мы обнаружили много интересного и в результате приняли несколько важных решений.
Какие именно – читайте в следующей статье.
Теги: #unity #unity3d #testing #UTR #Unified Test Runner #bugs #translation #Разработка игр #unity #Тестирование мобильных приложений #Тестирование игр
-
Улучшения В Технологии Hd-Dvr
19 Oct, 24 -
Привет От Леопарда
19 Oct, 24 -
Выпуск Outwiker 1.0.0
19 Oct, 24 -
Проект Psfreedom Портирован На Android
19 Oct, 24
