Ян Другаль уже 2 года создает инструменты разработки в Unity. За последнее время его команда значительно выросла, а вместе с этим и наборы тестов, количество неустойчивых, медленных тестов и невоспроизводимых ошибок. Мы публикуем перевод статьи о том, как Ян и его команда решают эти проблемы.
У нас в 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 есть множество направлений тестирования (рис. 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, где их обрабатывает аналитическое приложение.
В процессе обработки данных мы открыли много интересного и в результате приняли некоторые важные решения. Какие именно – читайте в следующей статье.
