Как автоматически тестировать превью-деплои Vercel в 2026 году

Короткий ответ

Вы не добавляете файл workflow и не пишете скрипт, вытаскивающий превью-URL из логов сборки. TestSprite устанавливается как GitHub App, слушает событие деплоя, которое ваш пайплайн уже производит, вычисляет превью-URL по шаблону, который вы задаете один раз, запускает по нему ваши тесты и публикует результат обратно в виде комментария в pull request.

Настройка занимает около десяти минут, требует прав администратора для установки GitHub App и не требует изменений в вашем репозитории.

Предварительное условие: убедитесь, что pull request порождает деплой

TestSprite запускается по событию деплоя, поэтому это событие должно существовать, прежде чем все остальное заработает. Откройте любой существующий pull request и убедитесь, что в нем указан деплой с кликабельным URL, затем откройте этот URL и проверьте, что превью-окружение действительно загружается.

В Vercel это выглядит как комментарий бота в pull request со списком проекта, статусом Ready и ссылкой на превью. AWS Amplify, Netlify и self-hosted пайплайны, создающие деплои GitHub, дают тот же сигнал в своем формате — важно лишь то, что деплой существует и его URL доступен.

Шаг 1 — подключите GitHub к своему workspace

Это одноразовая настройка для каждого workspace. В TestSprite перейдите в Workspace Settings → Integrations, найдите строку GitHub и нажмите Connect. Вас перенаправит в GitHub, чтобы выбрать организацию или личный аккаунт, которому принадлежит репозиторий, затем выберите All repositories или Only select repositories и нажмите Install & Authorize.

Стоит знать, какие права запрашиваются, прежде чем их одобрять:

Доступ на запись используется для публикации результатов тестов обратно в ваши pull request'ы и коммиты. TestSprite не пушит коммиты и не изменяет ваши файлы workflow. Если ваша организация не отображается при установке, у вас нет прав на установку GitHub App для нее — владелец организации должен одобрить установку.

Шаг 2 — подключите репозиторий к проекту

Откройте проект TestSprite, который хотите подключить, перейдите на вкладку GitHub Action и нажмите Connect GitHub Action. Затем выберите, как должны запускаться тесты:

Для начала достаточно одного триггера. Можно создать оба — они работают независимо друг от друга.

Шаг 3 — выберите событие, означающее «деплой завершен»

Выберите вкладку Pull Request, вставьте URL существующего pull request с рабочим превью-деплоем и нажмите Detect Events. TestSprite перечислит найденные в этом pull request CI/CD-события — проверки GitHub Actions, комментарии ботов от Vercel или Amplify, запуски workflow — и вы выбираете, какое из них запускает прогон.

Выберите событие, которое срабатывает после того, как деплой уже запущен и URL доступен. Это самая частая ошибка при настройке: событие, срабатывающее в начале сборки, запустит тесты по URL, который еще не поднят, и все тесты провалятся.

Шаг 4 — заполните шаблон целевого URL

Каждый хостинг-провайдер называет превью-URL по-своему, поэтому вы указываете TestSprite, как строить URL для любого данного pull request. Доступны пять плейсхолдеров:

Сверьте шаблон с настоящим превью-URL посимвольно:

Стандартные имена хостов превью в Vercel строятся из имени ветки, поэтому там обычно правильным плейсхолдером будет {branch-slug}, а не {pr}. Если ваш хостинг генерирует случайные субдомены без ничего предсказуемого в них, настройте стабильный alias-URL для превью-окружения и используйте его вместо этого.

Push-триггеру шаблон вообще не нужен — он запускается по настроенному URL того окружения TestSprite, которое вы выберете, так что выбирайте Dev для dev или Production для main.

Шаг 5 — отправьте тестовое событие перед сохранением

Нажмите Send Test Event. Это запускает ваши тесты по примерному pull request точно так же, как это сделал бы настоящий триггер, так что вы можете предпросмотреть весь поток, прежде чем зафиксировать настройку. Подождите примерно 30 секунд, затем вернитесь к pull request на GitHub — там появится комментарий TestSprite.

Откройте URL из этого комментария, прежде чем продолжать. Убедитесь, что он доступен и указывает на ожидаемое окружение. Если он неверен, исправьте шаблон и отправьте еще одно тестовое событие, а не ждите, пока это обнаружится при следующем pull request. Когда прогон завершится, TestSprite обновит тот же комментарий результатом.

Когда тестовое событие выглядит корректно, нажмите Create Trigger. Он появится в списке Triggers со статусом Active и будет запускаться автоматически на каждом будущем pull request. Стоит осознанно настроить два опциональных переключателя:

Если ваше превью находится за Deployment Protection

Это режим сбоя, который выглядит как успешная настройка. При включенной Deployment Protection в Vercel каждый превью-URL находится за стеной аутентификации, и внешний тестировщик вместо вашего приложения получает страницу входа. Тесты не выдают ошибку — они описывают страницу, которую никто не ожидал.

Проверка на Шаге 5 это отловит: откройте URL из комментария TestSprite в приватном окне. Если вы видите экран входа Vercel, защита включена. Два пути вперед — отключить защиту для превью-окружения или использовать Protection Bypass for Automation от Vercel, который генерирует секрет, принимаемый Vercel как параметр запроса x-vercel-protection-bypass, а также как заголовок. Поскольку шаблон целевого URL — это просто URL, форму с параметром запроса можно добавить прямо к нему:

https://app-git-{branch-slug}-team.vercel.app?x-vercel-protection-bypass=YOUR_SECRET

Сгенерируйте секрет в Project Settings → Deployment Protection → Protection Bypass for Automation. Будьте осторожны с этим — секрет обхода хранится в поле настроек, поэтому отключение защиты на превью-окружениях — более чистый вариант, если ваши превью не содержат ничего чувствительного.

Чтение результата

Когда прогон завершается, TestSprite обновляет свой комментарий в pull request — или проверку коммита — итогом. Комментарий структурирован, и последняя строка важнее всего, если код писал ИИ-агент:

Каждый результат ссылается на полный отчет в TestSprite.

Проверьте свою настройку

Прежде чем полагаться на интеграцию, убедитесь во всех пяти пунктах:

1. Интеграция GitHub отображается как Connected в вашем workspace

2. Репозиторий отображается во вкладке GitHub Action проекта

3. Триггер указан в списке и включен

4. Тестовое событие произвело комментарий TestSprite (pull request) или проверку (push)

5. URL в этом комментарии или проверке открывает правильно развернутое окружение

Устранение неполадок

Альтернатива через командную строку

GitHub App — правильный вариант, когда ваш пайплайн уже производит деплои. Если вы предпочитаете управлять прогоном из собственного workflow — или вы вообще не на GitHub — open-source TestSprite CLI выполняет ту же задачу из любой CI-системы. Он бесплатен для установки и лицензирован под Apache-2.0:

npm install -g @testsprite/testsprite-cli
testsprite setup

Укажите проекту URL, который вы уже определили, и запустите набор тестов до получения вердикта:

testsprite project update prj_abc123 --url "$PREVIEW_URL"
testsprite test run --all --project prj_abc123 --wait --output json
#   exit 0 = everything passed, exit 1 = something is broken

testsprite ci init github генерирует workflow для этого пути, а CLI требует в окружении только TESTSPRITE_API_KEY, так что он так же легко встраивается в CircleCI, GitLab, Jenkins или Azure Pipelines. Используйте --report junit --report-file <path> для sidecar-файла, который эти системы понимают нативно.

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

testsprite project update prj_abc123 \
  --username qa@example.com \
  --password-file ./.secrets/qa-password

Часто задаваемые вопросы