Тестирование и отладка

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

Методы тестирования

Ручное тестирование в редакторе Unity

Основной способ проверки работоспособности — запуск сцены SampleScene в редакторе и наблюдение за поведением игровых систем.

Что проверяется:

1. Инициализация — при запуске сцены появляется база, три рабочих, ресурсы начинают спавниться.
2. Сбор ресурсов — рабочие автоматически находят ресурсы, собирают их и доставляют на базу.
3. UI обновления — количество ресурсов в StorageView увеличивается после доставки.
4. Постройка рабочих — при нажатии кнопки «Build Worker» списываются ресурсы, через 10 секунд появляется новый рабочий.
5. Постройка базы — при достаточном количестве ресурсов можно построить вторичную базу.
6. Навигация — рабочие корректно обходят препятствия и движутся по NavMesh.
7. События — в консоли появляются логи при публикации событий (если включено логирование).

Тестовые сценарии

Для ускорения тестирования можно использовать предустановленные конфигурации:

• Быстрый старт: увеличить начальное количество ресурсов в хранилище, чтобы сразу тестировать постройку.
• Отключение спавна: временно отключить ResourceSpawner, чтобы проверить поведение при отсутствии ресурсов.
• Увеличение скорости: уменьшить интервалы сканирования и постройки, чтобы быстрее наблюдать циклы.

Инструменты отладки

Gizmos через GizmosAreaDrawer

Класс GizmosAreaDrawer позволяет визуализировать области (Area) в редакторе Unity. Это полезно для отладки зон базы (ожидания, доставки, появления) и области спавна ресурсов.

Как использовать:

1. Добавьте компонент GizmosAreaDrawer к любому игровому объекту.
2. В инспекторе укажите Area для отрисовки.
3. Выберите цвет и тип (проволочный или залитый).
4. В окне Scene (в режиме Gizmos) область будет отображаться как прямоугольник.

Unity Profiler

Для анализа производительности используется встроенный Unity Profiler (Window → Analysis → Profiler). Особое внимание стоит уделять:

• CPU Usage — нагрузка от скриптов (Update, корутины, события).
• Rendering — количество draw calls, треугольников, батчей.
• Memory — утечки памяти, размер текстур, мешей, объектов в пуле.
• Physics — затраты на NavMeshAgent.

Консоль и логирование

В коде используются стандартные методы логирования:

• Debug.Log — для информационных сообщений.
• Debug.LogWarning — для предупреждений (например, «Ресурсов недостаточно»).
• Debug.LogError — для ошибок (например, «Не удалось загрузить префаб»).

Событийная система также может логировать публикацию и подписку (если включить флаг LogEvents в IntelligentEventAggregator).

Breakpoints и пошаговое выполнение

Поскольку проект написан на C#, можно использовать отладчик Visual Studio (или Rider) для пошагового выполнения кода. Для этого:

1. Откройте проект в Visual Studio (через Open C# Project в Unity).
2. Прикрепите отладчик к процессу Unity (Debug → Attach to Unity).
3. Установите breakpoints в интересующих местах (например, в Worker.CollectResource).
4. Запустите игру в редакторе — выполнение остановится на breakpoint.

ThrowIf utility

Утилита ThrowIf (файл Assets/Scripts/Common/Utilities/ThrowIf.cs) предоставляет методы для проверки предусловий с выбрасыванием исключений.

Примеры использования:

public void SomeMethod(string name, int value)
{
    ThrowIf.Null(name, nameof(name));          // ArgumentNullException
    ThrowIf.OutOfRange(value, 0, 100);         // ArgumentOutOfRangeException
    ThrowIf.Empty(collection, nameof(collection)); // InvalidOperationException
}

Преимущества:

• Уменьшает boilerplate‑код (не нужно писать if (name == null) throw ...).
• Делает проверки единообразными по всему проекту.
• Улучшает читаемость.

Известные ограничения

Нет системы сохранения

Текущая версия не сохраняет прогресс между сессиями. При перезапуске игры все построенные базы, рабочие и собранные ресурсы теряются.

Возможное решение: реализовать сохранение через PlayerPrefs (для простых данных) или сериализацию в JSON (для сложных структур). Ключевые данные для сохранения:

• Позиции и состояние всех баз.
• Количество рабочих у каждой базы.
• Количество ресурсов в хранилищах.
• Позиции ресурсов на карте (или seed генератора).

Одна сцена

В проекте используется единственная сцена SampleScene. Это ограничивает возможность создания меню, загрузочных экранов, разных уровней.

Возможное решение: добавить сцены меню и переключаться между ними через SceneManager.LoadScene. Для этого потребуется перенести инициализацию (Bootstrap) в отдельную сцену‑загрузчик.

Нет локализации

Все тексты в UI на английском (или русском, в зависимости от ассетов). Добавление поддержки других языков потребует интеграции системы локализации.

Возможное решение: использовать I2 Localization или Unity Localization Package. Заменить жёстко закодированные строки на ключи и загружать переводы из CSV/JSON.

Нет системы звуков

В игре отсутствуют звуковые эффекты (сбор ресурсов, движение рабочих, постройка) и фоновая музыка.

Возможное решение: создать AudioService с пулом аудиоисточников и подписываться на игровые события (ResourceCollectedEvent, WorkerBuiltEvent) для воспроизведения соответствующих звуков.

Ограниченный UI

UI содержит только базовые элементы. Нет панели статистики, настроек, паузы, помощи.

Возможное решение: расширить UIManager (если есть) или создать отдельные презентеры для каждой новой панели.

Автоматическое тестирование

На данный момент в проекте отсутствуют автоматические тесты (юнит‑тесты, интеграционные тесты). Рекомендуется добавить тестовый фреймворк (например, Unity Test Framework) и покрыть тестами ключевые системы:

• PriorityQueue — корректность порядка элементов.
• Area и Rectangle — геометрические операции.
• ResourceStorage — добавление/удаление ресурсов.
• EventAggregator — подписка и публикация событий.

Пример юнит‑теста (псевдокод):

[Test]
public void PriorityQueue_Dequeue_ReturnsLowestPriority()
{
    var queue = new PriorityQueue<int, int>();
    queue.Enqueue(5, 5);
    queue.Enqueue(1, 1);
    queue.Enqueue(3, 3);

    Assert.AreEqual(1, queue.Dequeue());
    Assert.AreEqual(3, queue.Dequeue());
    Assert.AreEqual(5, queue.Dequeue());
}

Отладка в собранной версии

Для отладки на устройстве (например, на PC вне редактора) можно использовать:

• Файл логов: Unity пишет логи в %APPDATA%/../LocalLow/<CompanyName>/<ProductName>/output_log.txt (Windows). Добавить в код запись ключевых событий в файл.
• Удалённый профилировщик: подключить Profiler к работающей собранной игре (в меню Build Settings включить «Development Build» и «Autoconnect Profiler»).
• Консоль отладки: в Development Build можно открыть консоль нажатием Shift + Ctrl + C (Windows) для просмотра логов.

Рекомендации по улучшению тестируемости

1. Внедрение зависимостей: использовать интерфейсы и внедрение зависимостей (через конструкторы), чтобы легко подменять реальные реализации mock‑объектами в тестах.
2. Разделение логики и Unity‑зависимостей: выносить чистую логику в отдельные классы, не зависящие от MonoBehaviour, Time.deltaTime и т.д. Это позволит тестировать их без запуска Unity.
3. Тестовые данные: создать отдельные ScriptableObject с тестовыми конфигурациями (например, нулевая стоимость построек для быстрой проверки).
4. Интеграция CI/CD: настроить автоматический запуск тестов при каждом коммите (например, через GitHub Actions и Unity Cloud Build).