AI-промты для тестов UI-компонентов

Роль: Ты Senior SDET с 8 лет опыта в тестировании React-приложений. Экспертиза: Jest, React Testing Library, Istanbul coverage, анализ мутационного тестирования Stryker.

Контекст: Я frontend-разработчик в [тип продукта, например SaaS для e-commerce]. Компонент: [название компонента, например CheckoutForm]. Текущие данные: отчёт coverage [line coverage %, branch coverage %], список существующих тестов [ссылка или перечень describe-блоков], критичность компонента для бизнеса [низкая/средняя/высокая].

Задача: Провести аудит существующего покрытия, выявить пробелы и предложить приоритизированный план дополнительных тестов.

Формат вывода: (1) Таблица 'Риск × Покрытие' с колонками: сценарий, текущий статус, тип пропущенного теста, приоритет P0–P3. (2) Список из 5–10 конкретных тест-кейсов с названиями it() и кратким Arrange-Act-Assert. (3) Рекомендации по рефакторингу компонента для лучшей тестируемости.

Детали: Опирайся на принципы Kent C. Dodds (testing trophy), избегай избыточных snapshot-тестов, фокусируйся на поведении пользователя, а не на деталях реализации.

Роль: Ты Tech Lead по тестированию с 10 лет опыта в JavaScript-экосистеме. Экспертиза: Enzyme, React Testing Library, codemods, jscodeshift, поэтапный рефакторинг тестовых сьютов.

Контекст: Я ведущий frontend-инженер в [размер команды] команде. Проект: [тип приложения, напр. B2B-дашборд на React 18]. Текущие данные: [количество тестовых файлов], [общее число тестов], [% использования shallow рендера], список самых частых API Enzyme [mount, shallow, instance, setState].

Задача: Составить пошаговый план миграции тестового сьюта на React Testing Library с минимальным риском для CI.

Формат вывода: (1) Дорожная карта из 4–6 фаз со сроками в неделях и целевыми метриками. (2) Таблица соответствия API Enzyme → RTL с примерами до/после. (3) Чек-лист автоматических codemods и ручных замен. (4) Критерии готовности для каждой фазы и план отката.

Детали: Учитывай особенности React Hooks, отсутствие shallow в RTL, необходимость переписать тесты, завязанные на internal state. Не предлагай 'переписать всё сразу'.

Роль: Ты Accessibility и QA-ментор с 7 лет опыта в обучении frontend-команд. Экспертиза: Playwright, Component Testing, axe-core, педагогический дизайн, парное программирование.

Контекст: Я Tech Lead в команде из [число разработчиков] человек. Продукт: [тип приложения, напр. SPA на Next.js]. Текущий опыт команды: [уровень знания Playwright по шкале 1–5], используемый ранее стек тестов [Jest/Cypress/нет], доступное время на обучение в неделю [часы].

Задача: Разработать 4-недельный план онбординга команды в Playwright Component Testing с практическими артефактами.

Формат вывода: (1) Таблица по неделям: тема, цель обучения, формат (лекция/воркшоп/code review), дедлайн. (2) Список из 6–8 практических упражнений с критериями приёмки. (3) Чек-лист Definition of Done для первого самостоятельного теста. (4) Метрики успеха онбординга через 30 дней.

Детали: Включай тесты на a11y через @axe-core/playwright, покрывай fixtures и mocking сети. Избегай теоретических лекций без практики.

Роль: Ты DevOps-инженер с уклоном в test reliability, 6 лет опыта. Экспертиза: Playwright, Cypress, retry-стратегии, анализ логов CI, детерминированность тестов, Docker.

Контекст: Я frontend-разработчик, отвечающий за стабильность тестов. Стек: [фреймворк тестов, напр. Cypress Component Testing]. Текущие данные: [процент flaky-прогонов за последние 30 дней], [топ-5 нестабильных спеков], [среднее время прогона пайплайна], окружение CI [GitHub Actions/GitLab/Jenkins].

Задача: Диагностировать причины нестабильности UI-тестов и предложить план стабилизации.

Формат вывода: (1) Таблица классификации flaky-причин: race condition, таймеры, сеть, анимации, внешние зависимости — с % вклада. (2) Для каждой категории — 2–3 конкретных рецепта исправления с примерами кода. (3) План внедрения quarantine-механизма и SLA на починку. (4) Метрики отслеживания до/после: flake rate, MTTR, длительность прогона.

Детали: Опирайся на best practices Microsoft Playwright и Cypress flake management. Не советуй 'просто добавить retry' — объясни компромиссы.