Дублирую ссылки из презентации.

Видео:
- https://youtu.be/vLvA7ZkFGRo - теория по юнит тестам
- https://youtu.be/arzREy5zLVU - теория по tdd и пример кода
- https://youtu.be/TyxDg70hc3g - примеры кода
- https://youtu.be/6mkrxvyZp0Y - большой стрим от синдикатов

Статьи:
- Mastering Unit Testing in Unity 3D (https://kristobiasson.medium.com/mastering-unit-testing-in-unity-3d-8c8805accf1a)
- Unit Testing Best Practices (https://medium.com/@kaanfurkanc/unit-testing-best-practices-3a8b0ddd88b5)
- Документация Unity: Unity Test Framework (https://docs.unity3d.com/2022.1/Documentation/Manual/testing-editortestsrunner.html)
- Руководство для Unity-разработчика: Модульное тестирование (https://habr.com/ru/companies/otus/articles/913906/)
- Советы по тестированию и обеспечению качества для проектов Unity (https://unity.com/ru/how-to/testing-and-quality-assurance-tips-unity-projects?ysclid=mb9svd93b4232429255)

Запоздалая ссылка на стрим.
Был без интернета, так что сам в записи буду смотреть)

Assembly Definition

Привет!
Продолжая тему тестирования (а точнее предвосхищая ее) разберём мощный инструмент для организации кода в Unity - Assembly Definition.

❌По умолчанию все скрипты Unity компилирует в одну сборку (Assembly-CSharp.dll). Это вызывает проблемы:
* Медленная перекомпиляция (изменение любого скрипта пересобирает весь проект).
* Хаотичные зависимости (любой класс может обратиться к любому другому, даже если это не нужно).
* Сложность поддержки (в больших проектах трудно отслеживать связи между системами).

✅ Assembly Definition позволяет:
* Разделять код на независимые сборки (скрпиты одной сборки не "видят" скриптов другой, если между ними не настроена явная зависимость)
* Чётко контролировать зависимости между модулями
* Ускорять компиляцию (изменения затрагивают только нужные сборки)

⚠️ Для редакторских скриптов и тестов требуются отдельные .asmdef с настройками:
* Editor-скрипты: "Editor" в имени и включённая опция "Editor"
* Тесты: включить "Test Assemblies"

Assembly Definition и Namespace

Namespace – логическая группировка кода (защита от конфликтов имён)
Assembly Definition – физическое разделение на DLL

Можно ли обойтись без Namespace?

Технически — да, но крайне не рекомендуется тк:
* Риск конфликтов – если в разных сборках есть классы с одинаковыми именами
* Сложность навигации – без пространств имён труднее понимать структуру проекта
* Нарушение инкапсуляции – классы в глобальном пространстве видны везде

Представьте, например:
У вас есть сборка GameLogic и UI.
* В обеих есть класс Player (например, GameLogic.Player и UI.Player).
* Без namespace компилятор не поймёт, какой Player вы имеете в виду → ошибка.
С namespace конфликта нет, даже если классы в одной сборке.

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

Базовая настройка:
1. Создаём .asmdef-файл
* в папке (подпапке) со скриптами: ПКМ → Create → Assembly Definition
* Даём понятное имя (например, GameLogic, UI, Network, обычно как имя подпапки или пространства имен)
2. Настраиваем зависимости, чтобы скрипты одной сборки могли работать со скриптами другой.
Например, если сборка UI использует классы из GameLogic:
* Выбираем в окне Project наш UI.asmdef
* В инспекторе в Assembly References добавляем GameLogic
3. Другие важные параметры сборки:
* Auto Referenced – разрешает доступ из стандартных сборок Unity
* Override References – ручное управление зависимостями
* No Engine References – полностью отключает доступ к Unity API (для чистого C# кода)

Структура папок

Scripts/
├── GameLogic/
│ ├── Gameplay/Player.cs (скрипт в namespace Gameplay)
│ └── GameLogic.asmdef (файл сбрки)
├── UI/
│ ├── Windows.cs (namespace UI)
│ └── UI.asmdef (зависит от GameLogic)
└── Tests/
├── Characters/HealthTest.cs (namespace Tests)
└── Tests.asmdef

✅ Рекомендации

1. Связывайте имена сборок, папок и namespace

// В сборке GameLogic.asmdef, лежащей в папке GameLogic
namespace GameLogic
{
    public class Player { ... }
}

2. (Не злоупотреблять) Используйте вложенные namespace для сложных систем

namespace GameLogic.AI 
{
    public class EnemyBehavior { ... }
}

3. Избегайте циклических зависимостей
Сборка A не должна зависеть от B, если B уже зависит от A

4. Избегайте глобального пространства имён (классов без namespace)

Итоги

Assembly Definition даёт:
✅ Быструю компиляцию
✅ Чёткую архитектуру
✅ Лёгкий рефакторинг
✅ Защиту от случайных зависимостей

#оптимизация #архитектура

Привет!
Тут Яковлев выкатил довольно неплохую дорожную карту, для Unity Джуна от 0 до устройства на работу. Можете использовать её как чек лист для проверки знаний.

В целом, с таким пулом знаний можно даже борзонуть и на мидловые позиции откликаться.

https://miro.com/app/board/uXjVJXnVs1s=/?share_link_id=197903878291