Тестирование AI-веб-разработки: половина цикла, отвечающая за проверку

Куда должно смотреть тестирование AI-веб-разработки

Ничего из этого не видно в диффе — поэтому ускоренное ревью не помогает. Зато всё это видно за тридцать секунд работы с запущенным приложением — поэтому проверять нужно именно там.

Почему тесты, написанные агентом, не замыкают цикл

Тесты, сгенерированные вместе с реализацией, наследуют её допущения. Если код исходит из того, что эндпоинт возвращает пустой массив, а не 404, тест проверяет ровно то же самое допущение и проходит. Покрытие есть, независимого сигнала нет.

Проверка, которая замыкает цикл, должна прогонять развёрнутый продукт против ожидаемого поведения, а не против представлений кода о самом себе.

Как сохранить скорость, чтобы этим реально пользовались

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

Как удержать цикл достаточно коротким, чтобы им пользовались

Шаг проверки, который ощущается медленным, будут пропускать, и это рациональное решение, — поэтому темп важен не меньше покрытия.

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

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

Как встроить это в цикл

Установка добавляет навык проверки в кодинг-агента, так что проверка происходит там же, где идёт работа, а не превращается в отдельную рутину.

Если вы предпочитаете ничего не устанавливать, то же самое делает дашборд. Всё остальное, что умеет командная строка, описано в репозитории CLI.

• GitHub App — это вебхук, который вы настраиваете в дашборде TestSprite. Он слушает событие деплоя, которое ваш пайплайн и так порождает, поэтому в репозитории ничего менять не нужно.

• GitHub Actions встраивает этот шаг внутрь вашего собственного рабочего процесса и настраивается из терминала.

Что проверяет TestSprite и чего не может проверить агент

Развёрнутое приложение — против того, что вы описали как ожидаемое поведение, а не против того, что предполагает код. Смысл именно в этой независимости: тесты, написанные рядом с реализацией, наследуют её допущения и потому согласуются с ней в том числе там, где ошибаются оба.

Установка добавляет навык проверки в вашего кодинг-агента, так что проверка выполняется как часть внесения изменения. Шаги описываются намерениями, а не селекторами, а сбой возвращается одним пакетом, с которым агент может работать, — благодаря этому исправление остаётся в том же цикле, что и само изменение.

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