Как проверять сгенерированный ИИ код перед мерджем

Проблема проверки кода, который вы не писали

ИИ-агент по написанию кода может выдать рабочую фичу за минуты. Узкое место сместилось: ограничение теперь не в том, как быстро пишется код, а в том, насколько уверенно кто-либо может сказать, что код делает то, что должен. Внимательное чтение большого диффа занимает больше времени, чем заняла его генерация.

Проверки типов и юнит-тесты подтверждают, что код делает то, для чего был написан. Они не могут сказать вам, работает ли развернутое приложение, потому что никогда его не открывают. Именно в этом разрыве и живут реальные регрессии, порожденные ИИ.

Цикл в три команды

Установите open-source TestSprite CLI — бесплатный, Apache-2.0, Node 20.19+, 22.13+ или 24+:

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

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

# 1 — create the test and run it
testsprite test create --project prj_abc123 --type frontend \
  --plan-from ./checkout-flow.plan.json --run --wait --output json
#   → exit 1: the run failed

# 2 — pull ONE self-consistent failure bundle
testsprite test failure get test_3a9f21c7 --out ./.testsprite/failure

# 3 — fix the code, then replay the same test
testsprite test rerun test_3a9f21c7 --wait --output json
#   → exit 0: passed

Пакет данных на втором шаге — это та часть, которая имеет значение. Он содержит проваленный шаг, соседние с ним шаги, скриншоты, снимки DOM, исходный код теста, гипотезу о первопричине и рекомендуемую цель для исправления — и все это привязано к единому id снимка. CLI отказывается объединять данные из двух разных прогонов, так что агент никогда не рассуждает над контекстом, собранным из двух разных состояний приложения.

Почему устойчивый набор тестов лучше, чем большее контекстное окно

Каждый пройденный тест закрепляется. В следующий раз, когда агент коснется кодовой базы, это требование по-прежнему проверяется — независимо от того, есть ли о нем упоминание в текущем разговоре.

Это структурный аргумент в пользу внешней проверки. Контекстное окно хранит то, о чем агент думает прямо сейчас. Набор тестов хранит каждое требование, которое проект когда-либо выполнял правильно, и продолжает хранить их между сессиями, между агентами и через месяцы, когда уже никто не помнит, почему тот или иной крайний случай был важен.

Настройте своего агента, чтобы он делал это сам

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

TESTSPRITE_API_KEY=sk-... testsprite setup --from-env --yes --agent claude

Поддерживаемые среды — это claude, codex, cursor, cline, antigravity, kiro, windsurf и copilot. Установка выполняется полностью локально. После этого агент знает, как создавать, запускать и разбирать тесты, и ему не нужно повторять это в каждой сессии.

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

testsprite doctor    # CLI and Node versions, profile, credentials, connectivity

Что проверять в первую очередь

Не все заслуживает сквозного теста. В кодовой базе, быстро меняющейся под управлением ИИ-агента, самое ценное покрытие узкое:

1. Потоки, приносящие доход. Регистрация, оформление заказа и биллинг. Регрессия здесь стоит денег немедленно и часто незаметна в юнит-тестах.

2. Все, что связано с аутентификацией. Работа с сессиями, редиректы после входа и границы разрешений — это то, где правдоподобно выглядящий рефакторинг наносит наибольший ущерб.

3. Формы и валидация. Дешево описать, но непропорционально высок шанс поломки при обновлении библиотеки компонентов или переименовании поля.

4. Последние три бага, которые вы выпустили. Регрессионный тест, написанный после исправления, — самый высокоокупаемый тест в любом наборе.

Если вы предпочитаете, чтобы первый набор был предложен за вас, разведка (exploration) может составить черновик. Предложения выкладываются на ревью, и ничего не записывается на диск, пока вы не примете их:

testsprite test plan generate --project prj_abc123
testsprite test plan accept --project prj_abc123           # all of them
testsprite test plan accept --project prj_abc123 --only prop_2 prop_5

Сделать проверку обязательной

Шаг проверки, который запускается только тогда, когда кто-то о нем вспоминает, — это не проверка. Поместите его в CI:

testsprite ci init github

Это генерирует .github/workflows/testsprite.yml с использованием TestSprite/testsprite-action@v1, который отмечает по одной ошибке за каждый провал на вкладке проверок PR, добавляет таблицу результатов в сводку задания, загружает отчет JUnit и — что важно — проваливает задание при частичном прогоне, а не отмечает его зеленым.

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

В любой другой CI-системе CLI требует в окружении только API-ключ:

export TESTSPRITE_API_KEY="$TESTSPRITE_API_KEY"
testsprite test run --all --project prj_abc123 --wait \
  --report junit --report-file testsprite-junit.xml \
  --summary-file testsprite-summary.json

Коды выхода, на которые стоит ветвиться

Коды 129, 130 и 143 означают, что процесс был прерван сигналом (128 плюс номер сигнала), а не что тест провалился, — стоит различать это, прежде чем сообщать о прогоне как о сломанном.

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