React и Vue — фронтенд-прогон рядом с бэкендом

Что обычно болит

Фронтенд почти всегда тестируется отдельно от бэкенда: свой пайплайн, свои отчёты, свой набор договорённостей. Когда падает сквозной сценарий, начинается разбирательство, чья это половина, и оно ведётся в чате.

Второе — устройства и браузеры. Проверка «на десктопе и на телефоне» существует в голове тестировщика, а не в артефактах, поэтому вопрос «а на Safari смотрели?» перед релизом задаётся каждый раз заново.

Что даёт QA Деск

Один проект на продукт. Кейсы фронтенда и бэкенда живут в одном реестре с общими метриками; сквозной сценарий не разрывается по границе команд.

Конфигурации среды в прогоне. Ручной прогон ведётся по конфигурациям — браузер, устройство, окружение. Ответ «на Safari смотрели, вот прогон» появляется сам.

Отчёт любого раннера. Vitest, Jest, Playwright, Cypress — нужен JUnit XML или Allure, всё остальное неважно.

Ошибки у пользователя — в дефекты. Sentry для браузера ловит то, что не воспроизводится локально; ошибка становится дефектом со ссылкой на issue. См. Sentry.

Рецепт: отчёт из вашего раннера

# Vitest
vitest run --reporter=junit --outputFile=reports/junit.xml

# Jest — репортёр jest-junit
jest --reporters=default --reporters=jest-junit

# Playwright — репортёр junit
npx playwright test --reporter=junit

Cypress отдаёт JUnit через mocha-junit-reporter; несколько файлов от разных спеков склеиваются в один прогон автоматически.

Шаг выгрузки — один на все случаи:

QADESK_TOKEN=qdit_… qadesk-cli upload --run "web e2e" --env stage --platform web ./reports

Ключ кейса

// Vitest / Jest
it('QAD-C52 корзина сохраняется после перезагрузки', async () => { /* … */ });

// Playwright — ключ в имени теста работает так же
test('QAD-C52 корзина сохраняется после перезагрузки', async ({ page }) => { /* … */ });

Тест без ключа не попадёт в покрытие и вернётся в списке несматченных с причиной — это видно сразу в выводе пайплайна, а не через месяц по расхождению цифр.

Компонентные, интеграционные, сквозные

Отдавать в деск имеет смысл не всё подряд. Юнит-тесты компонентов измеряются тысячами, меняются каждый день и ничего не говорят о продукте на языке заказчика — им место в CI. В покрытие полезно поднимать сквозные сценарии: регистрация, оформление заказа, оплата, работа с ролями. Их немного, они формулируются словами пользователя и совпадают с ручными кейсами один к одному.

Практическое правило: если у сценария есть шанс когда-то стать ручной проверкой перед релизом — ему нужен ключ кейса. Остальное пусть остаётся зелёным в пайплайне.

Кроссбраузерность без матрицы в голове

Прогоны Playwright на нескольких браузерах приезжают как разные отчёты — разделяйте их именем прогона и полем платформы:

qadesk-cli upload --run "e2e chromium" --platform web ./reports/chromium
qadesk-cli upload --run "e2e webkit"   --platform web ./reports/webkit

Если шарды одного прогона, задайте свой --attempt на шард: приём идемпотентен по паре «прогон CI + попытка», и одинаковый ключ с разным содержимым получит честный отказ, а не тихую перезапись.

Дефект от фронтенда, который примут без вопросов

Поля дефекта закрывают ровно то, о чём разработчик обычно спрашивает первым: окружение, платформа, сборка. Дальше остаются шаги и вложение — скриншот или короткая запись экрана. Если ошибка пришла из Sentry, в карточке уже есть тип исключения и ссылка на issue, и пересказывать стек-трейс словами не нужно.

Чего в продукте нет

• нет визуального сравнения скриншотов и хранения снапшотов — это работа раннера;
• нет npm-пакета: qadesk-cli — статический бинарник, ему не нужен Node в раннере;
• нет автоматической связи «упавший тест → дефект»: флаки-тесты превратили бы трекер в шум.

С чего начать

1. Заведите проект и выпустите токен приёма.
2. Включите JUnit-репортёр в раннере, который уже используется, и добавьте шаг выгрузки.
3. Возьмите смоук каталога и заказа как основу для e2e-набора — он написан от лица пользователя, а не компонентов.
4. Заведите конфигурации среды под браузеры, которые вы реально поддерживаете, и проведите первый ручной прогон по ним.

Рядом по теме

Автотесты, CI и мониторинг

Playwright

Playwright пишет отчёт, QA Деск делает из него прогон: ключ кейса связывает автотест с ручной проверкой, повтор задания не плодит дубли, а упавший сценарий превращается в дефект.

Playwright — сценарии в браузере, результат в покрытии Автотесты, CI и мониторинг

JUnit XML

Своего формата у QA Деск нет: подойдёт JUnit XML, который ваш раннер уже пишет. Один запрос из пайплайна — и отчёт становится прогоном с историей, покрытием и дефектами.

JUnit XML — формат, который умеет писать всё Автотесты, CI и мониторинг

Sentry

Ошибка уровня error или fatal становится дефектом выбранного проекта — с типом исключения, местом и ссылкой на issue. Одна ошибка — один дефект, повторные срабатывания дублей не плодят.

Sentry — ошибка у пользователя приходит дефектом