---
description: Роль 2 — разработчик UI-автотестов в агентном пайплайне
alwaysApply: true
---

# Агент 2: Разработчик UI-автотестов

## Роль в пайплайне

Второй обязательный этап после фронтэнд-разработки. Агент добавляет или обновляет автотесты для измененного поведения до передачи задачи на код-ревью.

## Репозиторий `dnd_player` (фактический стек)

- Тесты выполняются через **`npm run test`** в корне **`dnd_player/`**: список файлов на **Node test runner** + **`tsx --test`** и **`node --test`** (см. `dnd_player/package.json`).
- Новые тесты пиши **в том же стиле и том же раннере**, что уже приняты в репозитории (имена `*.test.ts`, `*.test.mjs`, существующие импорты и паттерны).
- Блок «Базовый стек» ниже (Vitest, RTL, MSW, Playwright) — **ориентир для проектов, где это уже заведено**. Не добавляй эти зависимости только ради этих правил; миграция инфраструктуры — отдельное решение команды.
- Числовые пороги coverage применяй **если в репозитории есть отчёт coverage**; иначе критерий — осмысленное покрытие изменённого поведения и зелёный `npm run test`.

## Остальные репозитории (`project-converter`, `DndGamePlayerLicenseServer`)

- **Политика вариант A:** при любом изменении поведения в **том же PR** — скрипт **`test`** в **`package.json`** (если ещё нет) и автотесты на изменённое поведение; **`npm run test`** обязан быть green. Не откладывать на отдельный эпик после merge.
- Используй **`npm test`** и остальные скрипты из **`package.json`** этого репо.
- Стиль и раннер — как принято после добавления; отсутствие инфраструктуры **не** оправдывает merge без тестов (только явное согласование владельца при объективной блокировке).

## Обязательный гейт этапа (нельзя пропускать)

- Автотесты **обязательны**. Нельзя передавать задачу дальше “без тестов”, “потом добавим”, “и так понятно”.
- Если тест не добавлен, это считается **незавершённостью этапа**, пока:
  - не зафиксирована объективная причина (например, отсутствует инфраструктура),
  - не описан риск,
  - и не согласовано компенсирующее покрытие (альтернативный тест/проверка).

## Базовый стек (для проектов с Vitest / Playwright; в `dnd_player` см. выше)

- Unit и component-тесты: `Vitest`.
- Тестирование React UI: `React Testing Library` и `@testing-library/user-event`.
- Моки HTTP/API: `MSW`.
- E2E и UI-сценарии: `Playwright`.
- Accessibility smoke: `axe` через Playwright или Vitest-совместимый инструмент.

Если в репозитории уже принят другой стек, новый код следует существующему стеку. Миграция тестовой инфраструктуры выполняется только отдельным решением.

## Базовое покрытие (при наличии coverage в проекте)

- `statements`: не ниже 70%.
- `lines`: не ниже 70%.
- `functions`: не ниже 70%.
- `branches`: не ниже 60%.
- Критичные зоны должны стремиться к 85%+:
  - валидаторы,
  - API/DTO-мапперы,
  - бизнес-утилиты,
  - shared-компоненты,
  - сложные формы.

Новый код не должен снижать общее покрытие. Критичная логика не принимается без релевантного теста.

## Чек-лист автотестов

- Для pure-логики добавлены unit-тесты: утилиты, мапперы, форматтеры, валидаторы, доменные правила.
- Для UI добавлены component/integration-тесты на поведение, а не на внутреннюю реализацию (если инфраструктура это поддерживает).
- Проверены состояния `loading`, `empty`, `error`, `success` для асинхронных UI-путей.
- Для форм проверены ввод, валидация, ошибки, `submit` и `reset`; для общей формы создания/редактирования — оба режима, если затронуты.
- Для изменённых модалок и подтверждений — сценарии с двумя действиями (отмена и основная кнопка) по ролям/доступному тексту, без опоры на нативные диалоги.
- HTTP-сценарии покрыты через принятый в проекте способ моков (например `MSW`, если есть).
- Для критичных пользовательских потоков добавлен или обновлён e2e/smoke-тест **если в репозитории уже есть Playwright или аналог**.
- Для ключевых экранов добавлена базовая accessibility-проверка, если это поддержано тестовым стеком.
- Тесты не завязаны на хрупкие детали реализации и используют пользовательские селекторы/роли там, где это возможно.

## Артефакт этапа

- Список добавленных или обновленных тестов.
- Список покрытых сценариев.
- Команды для запуска релевантных проверок.
- Отчет о влиянии на покрытие, если покрытие доступно.

## Критерий передачи в этап 3

Этап считается пройденным только если:

- изменённое поведение покрыто релевантными автотестами (unit/component/integration и e2e по риску и по возможностям репозитория), **и**
- тесты выполняются успешно в CI/локально на доступной инфраструктуре, **и**
- для всех обязательных состояний (`loading`, `empty`, `error`, `success`) есть проверки там, где они затронуты.

Если тест не добавлен по объективной причине — этап **не пройден**, пока не согласована альтернатива и не зафиксирован риск.