Поделиться через

Участие в MRTK3

  • Статья

MRTK3 — это проект с открытым кодом с лицензией MIT. Мы приветствуем и ценить вклад сообщества как за новые функции, так и за исправления ошибок.

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

Руководство по вкладу

  1. Создание вилки репозитория MRTK в учетной записи GitHub.

  2. Клонируйте вилку репозитория MRTK, следуя нашему руководству по началу работы с проектом шаблона . Убедитесь, что у вас есть необходимые инструменты, особенно правильная версия Unity. Чтобы убедиться, что вы находитесь в правой ветви, клонируйте с помощью команды :

git clone --branch mrtk3 YOUR_GIT_URL
  1. Создайте новую ветвь для изменений или исправлений.
git checkout -b yourchange_fix

  1. Откройте проект шаблона, MRTKDevTemplate расположенный в UnityProjects/MRTKDevTemplate. Вы можете добавить проект в Unity Hub для удобного доступа.

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

  3. Откройте запрос на вытягивание в репозитории MRTK, ориентированном на ветвь mrtk3 . Убедитесь, что вы точно опишите внесенные изменения и примените соответствующие метки к запросу на вытягивание для лучшей классификации и рассмотрения. Если вы являетесь новым участник MRTK, вам может потребоваться подписать наше соглашение об участии.

  4. Устраните все исправления, запрошенные сообществом или командой обслуживания, и объедините запрос на вытягивание после утверждения.

Написание тестов

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

Чтобы написать модульные тесты, рекомендуется сначала ознакомиться с существующими модульными тестами и узнать, как служебные программы и симуляторы тестов MRTK используются для имитации входных данных XR. Вы можете имитировать ручной ввод, взгляд, положение HMD и другие основные функции, связанные с вводом. Вот некоторые общие рекомендации по написанию хороших модульных тестов:

  • Попробуйте написать более детализированные тесты, которые оценивают небольшие функциональные возможности, а не более крупные монолитные тесты. Более детализированные модульные тесты позволяют обслуживателям видеть, какая конкретная функция была нарушена. Более общие комплексные тесты функциональности также ценятся, но убедитесь, что каждая меньшая часть функции хорошо протестирована для начала.
  • Убедитесь, что тест (и функция) не делает никаких предположений об ориентации или расположении пользователя. Тесты и функции должны работать при любом произвольном смещении или повороте от источника мира.
  • Если тесты имитируют введенные пользователем данные, убедитесь, что используется наш подкласс BaseRuntimeInputTests, который гарантирует, что правильная тестовая ремень настроена и снесен.
  • Используйте параметризацию NUnit, чтобы легко увеличить разнообразие и гибкость теста. См. документацию по параметризованным тестам NUnit здесь.
  • Для регистрации некоторых входных данных или взаимодействий может потребоваться несколько кадров. Вы можете использовать для yield return RuntimeTestUtilities.WaitForUpdates() добавления дополнительных кадров задержки в тест, если взаимодействие не регистрируется.
  • Попробуйте написать модульные тесты, которые выполняются как можно быстрее, чтобы избежать медленной итерации CI.
  • Убедитесь, что вы добавили соответствующие тестовые зависимости в package.json, а также правильные ссылки на файл определения сборки папки тестов.

Непрерывная интеграция

Перед слиянием каждый запрос на вытягивание проходит автоматические тесты. Другие задания непрерывной интеграции (CI) также выполняются в результирующей фиксации в ветви разработки main, чтобы гарантировать, что неисправные пакеты не будут развернуты в веб-канале.

Если тесты сдаются в редакторе, но не выполняются при выполнении CI, тесты следует выполнять локально в пакетном режиме. Некоторые типы тестов могут неожиданно завершиться ошибкой при выполнении в пакетном режиме без графики из-за различий во времени или других причуд Unity. Локальное выполнение тестов в пакетном режиме помогает выявить эти несогласованные тесты до выполнения CI.

Используйте скрипт для локального Tooling/Tests/run_playmode_tests.ps1 запуска тестов в пакетном режиме. Для этого необходимо закрыть редактор Unity.

$ ./Tooling/Tests/run_playmode_tests.ps1

Скрипт создаст выходные файлы в папке /out , включая файлы .log и результаты .xmlтеста . Вы можете отфильтровать выполняемые тесты, передав в скрипт регулярное выражение. Пользовательские версии Unity и расположения папок проекта также можно указать в качестве аргументов.

$ ./Tooling/Tests/run_playmode_tests.ps1 -unityVersion 2021.3.5f1 -projectPath ../my/project/path