/does-it-work

name: does-it-work
description: >
  Проверка, что продукт реально работает, и защита его качества автотестами.
  Аудит работающего (в т.ч. навайбкоженного) приложения: найти баги, оценить
  готовность к проду, выдать баг-репорт с severity. Генерация тестовых фреймворков:
  API-тесты на Python (pytest + httpx + Pydantic + Allure) и Java (JUnit 5 +
  REST Assured), WEB/UI-тесты (Playwright, Selenium, Selenide, Page Object);
  конвертация OpenAPI/Postman/curl/HAR в тесты, негативные кейсы, контракты.
  Также стабилизация флакающих тестов и ревью качества тестов.
  Triggers: "проверь мой продукт/приложение", "найди баги", "навайбкодил",
  "можно ли в прод", "работает ли оно", "vibe code", "напиши автотесты",
  "сгенерируй тесты", "покрой тестами", "e2e тесты", "UI-тесты", "Playwright",
  "REST Assured", "generate tests", "стабилизируй тесты", "flaky", "тесты
  флакают", "ревью тестов", "проверь качество тестов".

does-it-work: проверка продукта и защита качества автотестами

Скилл отвечает на вопрос «а оно вообще работает?»: прогоняет живое приложение тестами, находит баги (репорт с severity) и оставляет каркас автотестов как защиту от регрессий. Пять эталонных каркасов в `templates/` — все **проверены запуском** против живых стендов. Копируйте их структуру и стиль, а не пишите с нуля.

Оформление (все ветки): имена функций/переменных — латиницей, docstrings, allure-тайтлы, шаги и тексты assert-сообщений — **на русском**.

Выбор ветки

| Задача | Стек | Шаблон | |---|---|---| | API-тесты на Python (дефолт для API) | pytest + httpx (sync) + Pydantic | `templates/api-python/` | | API-тесты на Java | JUnit 5 + REST Assured + Maven | `templates/api-java/` | | UI-тесты на Python (дефолт для WEB) | Playwright + Page Object | `templates/web-python-playwright/` | | UI-тесты на Python (легаси/требование) | Selenium + Page Object | `templates/web-python-selenium/` | | UI-тесты на Java | Selenide + JUnit 5 | `templates/web-java-selenide/` |

Если тип (API/WEB) или язык не следует из запроса и контекста проекта — задай один вопрос пользователю до генерации. README каждого шаблона описывает паттерны своей ветки. Java- и WEB-шаблоны — проверенные примеры на реальном приложении RV Booker: замените ресурсы/страницы на свои, сохранив структуру слоёв.

**Общие конвенции всех веток** (подробно раскрыты ниже на python-ветке, остальные зеркалят): слои клиенты/страницы → модели → тесты по фичам; конфиг только из env-переменных (`API_TESTS_*` / `WEB_TESTS_*`); маркеры/теги smoke/critical/negative/flaky

• severity на каждом тесте; строгие контракты (Pydantic `extra="forbid"` / Jackson records);

никаких sleep — только ожидания (`wait_until` / Awaitility / встроенные в Playwright и Selenide); environment.properties и категории в Allure; зелёный прогон обязателен; «Самопроверка качества» и «Red flags» (секции ниже) применяются во всех ветках.

Специфика WEB-веток: Page Object (страница = класс, локаторы — свойства/константы, действия — методы с шагом); подготовка данных и **логин — через API** в обход UI (форма логина — отдельный тест); артефакты при падении (скриншот + HTML) в Allure; селекторы: стабильные id → роли → css, хрупкие xpath запрещены; мобильные вьюпорты и кросс-браузерная CI-матрица — в Playwright-шаблоне.

Маршрутизация: что читать под задачу

• **«Проверь мой продукт / найди баги / можно ли в прод»** (аудит навайбкоженного

или незнакомого приложения) → те же шаги 1–5, но главный деливерабл — не каркас, а вердикт: префлайт стенда → smoke ядра → карта покрытия → **баг-репорт с severity** ([examples/bug-report.md](examples/bug-report.md)) и ответ «что работает, что сломано, что не проверено». Каркас остаётся пользователю как защита от регрессий.

• **Новый проект с нуля** → выбор ветки (таблица выше) + весь порядок работы (шаги 1–5).
• **Дописать тесты в существующий проект** → шаг 1 (режим «существующий»), шаги 2, 4, 5.
• **Стабилизировать флакающие тесты** →

[reference/stabilize-and-review.md](reference/stabilize-and-review.md), режим «Стабилизация»: воспроизведи повторами → классифицируй причину → почини причину, не симптом → докажи N зелёными прогонами. Каркас не разворачивай.

• **Ревью существующих тестов** → там же, режим «Ревью»: сначала запуск, потом

чек-листы (включая шаг 5 ниже), находки с severity, отчёт до правок.

• **Только негативные кейсы / контракты** → шаг 2 + паттерны «негативные», «контракт»

из шага 3; каркас не разворачивай.

• **API с логином/ролями или общий стенд** → плюс

[reference/live-api-patterns.md](reference/live-api-patterns.md).

• **WEB-тесты** → README выбранного web-шаблона; разведай DOM живого приложения

(Playwright-скриптом) до написания Page Object'ов — не выдумывай селекторы.

• **Источник — не OpenAPI** (код, требования, curl/HAR) →

[reference/input-sources.md](reference/input-sources.md).

• **Стенд недоступен/сомнителен** → сначала `scripts/check_env.py` (см. шаг 2).

Порядок работы (шаги детализированы для api-python; остальные ветки зеркалят)

1. Определи режим

• **Новый проект** → разверни каркас из шаблона выбранной ветки, подставь реальные

эндпоинты/страницы вместо примера.

• **Существующий тестовый проект** → сначала изучи его: conftest, базовый клиент, стиль

именования, маркеры. Новые тесты пиши в стиле проекта; паттерны из `templates/` применяй только там, где в проекте нет своего решения. Не дублируй существующие фикстуры.

2. Извлеки тест-кейсы из источника

Источником может быть OpenAPI-спека, исходный код сервиса, текстовые требования или примеры запросов (curl/Postman/HAR). Рецепты по каждому — в [reference/input-sources.md](reference/input-sources.md). Если источник неоднозначен — задай вопросы пользователю до генерации, не додумывай.

Перед генерацией проверь стенд префлайт-скриптом — он покажет доступность, латентность и работоспособность авторизации до того, как ты напишешь хоть один тест. Скрипт лежит в директории скилла, а cwd при работе — проект пользователя, поэтому вызывай его по полному пут