Test Lab

Отдельная лаборатория acceptance- и системных тестов Portable Agent. Она не придумывает бизнес-правила: продуктовые ожидания берутся из документации platform. Лаборатория также проверяет общие свойства платформы: доступность, задержку, обработку ошибок и восстановление.

Быстрый старт

Copy-Item .env.example .env
task verify
task test:smoke

Все повседневные команды собраны в Taskfile.yml. Выполни task --list, чтобы увидеть их. На Windows Task сам использует Windows PowerShell, поэтому отдельная установка pwsh не нужна.

По умолчанию Compose поднимает только локальный fake-service. Для внешней среды явно передай TARGET_URL; production URL скрипты отклоняют. Пороги k6 хранятся рядом со сценарием.

Acceptance-тест встречи

tests/calendar-event.js описывает первый продуктовый путь: demo-команда создаёт предложение, действие ждёт подтверждения, после подтверждения завершается и создаёт ровно одно событие. Повтор с тем же requestKey не создаёт дубль.

Сначала подними полный локальный стенд в репозитории deploy. Затем заполни в локальном .env учётные данные только тестового пользователя и ключ проверочного API:

TEST_USERNAME=local-user
TEST_PASSWORD=<пароль локального пользователя>
CALENDAR_TEST_API_KEY=<локальный ключ Calendar MCP>

После этого запусти:

task test:e2e

Runner сам получает короткоживущий JWT у локального Keycloak. В CI вместо тестового логина и пароля можно передать готовый ACTION_TOKEN. Скрипт принимает только локальные HTTP-адреса. Проверочный API fake-calendar доступен только в тестовом режиме и требует отдельный X-Test-Key; секреты не хранятся в Git. Для одинакового запуска в Docker Desktop и Linux runner имя host.docker.internal явно связывается со стандартным Docker host-gateway. Если задан DOCKER_NETWORK, k6 подключается к существующей Compose-сети и принимает внутренние имена channel-gateway, action-service и calendar-mcp. Сам test-lab эту сеть не создаёт.

Путь начинается с публичной границы Channel Gateway, затем проходит через Agent Runtime, Action Service, Temporal и Calendar MCP. Один JWT передаётся по этому пути; каждый защищённый сервис самостоятельно проверяет подпись, issuer, срок и свой audience. Идентификаторы пользователя и tenant не передаются в JSON запроса: сервисы получают их из проверенных claims sub и tenant_id.

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

• unit-, component- и integration-тесты принадлежат репозиторию конкретного сервиса;
• здесь остаются только критические black-box пути пользователя, нагрузочные проверки и безопасные resilience-сценарии;
• test:e2e не поднимает сервисы и не управляет их жизненным циклом: за окружение отвечает deploy;
• production-адреса runner отклоняет до запуска теста.