Налаштування автоматичного тестування базових механік ігр
Ручне тестування працює доти, доки розробник один та релізи виходять раз у місяць. Як тільки команда виростає або цикл збірки прискорюється до кількох в день, ручний QA перетворюється на вузьке місце: тестувальник не встигає перевірити регресію по всіх механіках після кожного коміту. У результаті баги у фізиці або логіці прогресії доїздять до релізу.
Що ломається найчастіше та чому ручний тест це пропускає
Найчастіша історія—сломаний CharacterController після зміни параметрів slopeLimit або stepOffset. Працює в Editor, працює в швидкому ручному прогоні, але падає на конкретної комбінації швидкостей та кутів геометрії, яку тестувальник не відтворював. Play Mode Test з параметризованим входом—єдиний систематичний спосіб покрити граничні випадки.
Друга зона ризику—ігрова логіка зі станами. StateMachine персонажа або GameManager з флагами сесії легко отримують невалідний перехід: Idle → Attack без проходу через Ready, якщо в коді додали shortcut-перехід. Такий баг може відтворюватися лише при певної послідовності інпутів за 10 секунд—жоден тестувальник не буде гонять це вручну після кожного пуша.
Інструментарій та підхід
Основний стек для Unity—Unity Test Framework (пакет com.unity.test-framework), який дає два режими: EditMode Tests (без запуску сцени, чисті unit-тести) та PlayMode Tests (з повним життєвим циклом GameObject).
EditMode підходить для тестування чистої логіки: балансові формули, парсинг даних, розрахунок статів, генератори рівнів. Працює швидко, запускається в CI без GPU.
PlayMode потрібен для всього, що завязано на фізику (Rigidbody, CharacterController), анімації (Animator, Blend Tree переходи), коліції та корутини. Тут тест чекає реальні тики FixedUpdate.
Для VR-механік окрема історія: XR Interaction Toolkit надає XRSimulatedController та XRSimulatedHMD—використовуємо для симуляції позиції рук та голови без фізичного HMD. Це дозволяє гонять тести XRGrabInteractable та XRRayInteractor прямо в CI на безголовому агенті.
Структура тестів будується за шарами:
- Unit-тести на чисті методи (нема залежностей від MonoBehaviour)
- Integration-тести на взаємодію компонентів (наприклад, Inventory + PickupSystem + SaveSystem)
- Smoke-тести—швидкий прогон критичних механік після кожного коміту
- Regression-тести—повний прогон перед релізом
Інтеграція з CI будується через Unity Test Runner CLI: unity -batchmode -runTests -testPlatform EditMode -testResults results.xml. Результати парсимо в JUnit XML форматі, який розуміють GitHub Actions, GitLab CI, TeamCity.
Для Unreal Engine використовуємо Automation System (FAutomationTestBase, IMPLEMENT_SIMPLE_AUTOMATION_TEST)—принцип той же, різна нотація.
Що конкретно покриваємо тестами при налаштуванні
Набір базових механік, які закриваємо в першу чергу:
- Рух персонажа: перевірка швидкості, столкновень, прибуття на різних кутах геометрії
- Система здоров'я / урона: граничні значення (0 HP, від'ємний урон, імунітет)
- Інвентар: додавання, видалення, переповнення слотів, стакування предметів
- Збереження/завантаження: серіалізація стану та його коректне відновлення
- Логіка прогресії: розблокування рівнів, умови перемоги/поразки
Як будується робота
Аудит кодової бази. Дивимось, як написана логіка: є ли залежності від MonoBehaviour там, де їх можна видалити, використовується ли DI (Zenject, VContainer). Сильно з'язаний код потребує рефакторингу перш ніж написання тестів.
Виділення тестуємих одиниць. Там, де потрібно, виносимо логіку з MonoBehaviour у pure C# класи.
Написання тестів. Починаємо зі smoke-набору на критичні шляхи, потім розширюємо граничними випадками.
Налаштування CI pipline. Конфігуруємо запуск через Unity License Server або Unity Build Automation, налаштовуємо репорти.
Документація. Описуємо, як додавати нові тести, щоб команда підтримувала покриття самостійно.
| Об'єм задачі | Орієнтовні строки |
|---|---|
| Налаштування Test Framework + 10–15 базових тестів | 3–5 днів |
| Повний тестовий набір (50–80 тестів) + CI | 2–4 тижні |
| VR-проект з XRSimulated тестами | 3–5 тижнів |
Вартість розраховується індивідуально після аналізу архітектури проекту.