Search Unity

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

, 7 октября, 2015

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

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

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

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

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

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

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).

Figure 3. Build agents and humans submit data to Hoarder Web Service. Analytics application fetching it

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

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

15 replies on “UNIFIED TEST RUNNER И АНАЛИЗ ТЕСТОВЫХ ДАННЫХ”

Dear community,
I have a question. So, i can’t find information about this issue :
need automation tests for web enterprise application(unity player in web browser), when part of the data is loaded during rendering scenes (after play button). is it possible in Unity write and run tests at runtime?

Being in software dev industry for +20 years in customer/providers environments, I think one of the problem with QA resides in the fact that you don’t control runtime environment. This means that you can put lot of effort on patterns, good practices and quality controls, but that will cover just 50% of the potential issue surface (related mostly to dev/human errors along dev processes).

So yes, all of that stuff is incredibly good and should be done and continued. But in order to significantly reduce your bug report count (which is what matters to customers), you should think of:

— How to extend your quality processes/controls/monitors/detectors to the end-user environment (ie. my development machine as an Unity dev).
— Even further, how to extend your quality processes/controls/monitors/detectors to our own users environment (ie. my own customers).

But most important: understand that asset developers (like I) should be considered as part of your development community (being in an outer-layer from our common customers perspectives — gamers and users). What I mean is that as an asset developer I want usage metrics for my assets as you have for Unity in general, I want Unity to alert me when an upgrade breaks my assets functionality for any reason (ok, not daily but as soon as you publish a beta). I can’t handle the testing needed for every beta put out there for all my assets (well, I can, but I prefer to invest my time in providing real value).

Keep up the good work guys.

Sorry to sound a bit cynical but the latest release just broke input for Mac on standalone. How is that possible with such a great testing environment that a major platform becomes completely broken?

If only we could downgrade to a previous version, though lightmapping is unusable there when mixing the lightmap between Windows and Mac.

I agree, you’d have thought that if you know that you have something that your automated tests don’t cover, that’s as critical as keyboard input, then you might test it manually before releasing? Or at least fix it in one of the subsequent two patch release or point release? Seems like maybe you’re relying on automated tests too much.

Comments are closed.