Складання й тестування

Home · BASIC · UO API · A–Z · Examples · Languages

Вимоги для складання

• Windows x64 і 64-бітний PowerShell;
• .NET SDK, закріплений у global.json, або сумісний patch тієї самої feature band;
• доступний NuGet cache або мережа для відновлення пакетів;
• Node.js та npm, якщо потрібно перебудувати Eclipse Theia;
• достатньо дискового простору для NativeAOT і двох редакцій.

Використовуйте штатну Windows-команду складання з кореня вибраної редакції вихідного коду. Її PowerShell-реалізація перевіряє середовище, запускає тести, компіляцію та контроль вихідного каталогу. Не змінюйте global.json і lockfile пакетів без усвідомленого оновлення та повного повторного тесту.

Ручні .NET-перевірки

dotnet --version
dotnet restore .\ClassicUO.sln -p:NuGetAudit=false
dotnet test .\tests\ClassicUO.UnitTests\ClassicUO.UnitTests.csproj -c Release
dotnet test .\external\InjectionScript\src\InjectionScript.Tests\InjectionScript.Tests.csproj -c Release
dotnet test .\external\InjectionScript\src\InjectionScript.Lsp.Tests\InjectionScript.Lsp.Tests.csproj -c Release

Повну редакцію та редакцію без Basic потрібно відновлювати, складати й тестувати окремо. Успішне складання Full не доводить відсутності Basic UI або Runtime-залежностей у without-Basic.

Перебудова Eclipse Theia

Потрібна лише після зміни frontend IDE або розширення:

cd .\external\YokoTheia
npm install
npm run build

Не замінюйте lockfile або версії платформи без повторних перевірок IDE й мовного сервісу.

NativeAOT та ігрові дані

Готовий клієнт перевіряється як Windows x64 NativeAOT payload. Для графічного smoke test потрібні локальні дані Ultima Online; вони навмисно не входять до репозиторію.

Обов’язкові напрями перевірки

• тести ClassicUO для обох редакцій;
• тести InjectionScript Runtime;
• тести LSP та IDE;
• NativeAOT-складання без помилок компіляції;
• збереження вибраного AutoLoad окремо для персонажів;
• пошук і виконання процедур Basic Auto Load;
• збереження та виконання Basic Example;
• Save для нового й відкритого файла;
• повна ініціалізація документа без прокрутки;
• Run, Debug, Pause, Continue, Step і Stop;
• паралельні скрипти та зелені/жовті/зупинені індикатори;
• відповідність Runtime/API Manual і правильні Basic-приклади;
• локалізація й ізоляція редакції без Basic.

Перевірка архіву

Після створення ZIP:

1. розпакуйте його до чистого тимчасового каталогу;
2. порівняйте дерево та хеш кожного payload-файла зі staging-каталогом;
3. повторіть native payload probes для обох клієнтів;
4. опублікуйте SHA-256 ZIP у сусідньому .sha256.txt.

Автоматичні тести не замінюють візуальний запуск на справжньому сервері. Окремо перевіряйте рендеринг ігрових даних, серверні gump, специфічні пакети шарда й функції, чиї дані надсилає сервер.