Вайб-тестирование: описывайте проверки вместо того, чтобы их писать

Что вайб-тестирование убирает на самом деле

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

Второе, что уходит, — налог на поддержку. Шаг, выраженный как намерение, переживает редизайн, который жёстко заданный селектор не переживает: когда кнопка переезжает, намерение остаётся верным.

Где описанная проверка даёт сбой

Одна привычка, которая отличает настоящие проверки от декоративных

Специально сломайте то, что проверяете, и убедитесь, что проверка загорелась красным. Это занимает минуту, и это единственное свидетельство того, что проверка вообще к чему-то подключена.

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

С чего начать

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

Ничего из этого не требует терминала. Создайте проект в панели управления TestSprite, опишите проверку обычным языком и укажите на своё приложение. Разработчики в вашей команде могут делать то же самое из командной строки, если им так удобнее, — всё это есть в репозитории CLI.

Что описать первым

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

• Всё, что связано с деньгами или правами доступа. Самая высокая цена ошибки — и в обоих случаях всё ломается тихо.

• То, что сломалось последним. То, что однажды вас подвело, заслуживает постоянной проверки — и вы уже точно знаете, как её описать.

Как описать проверку, которая выдержит

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

У хорошего описания три части: исходное состояние, действие и что-то наблюдаемое после, что подтвердится при перезагрузке. «Как вошедший в систему пользователь без сохранённых фильтров, создайте фильтр с названием Recent, перезагрузите страницу и убедитесь, что он появился в боковой панели». Упасть может любая из частей, и падение подскажет, где именно.

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

А потом перестаньте решать, когда их запускать

Описанная или написанная в коде — проверка, которая ждёт человека, в загруженную неделю оказывается пропущенной.

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

Что TestSprite делает с описанной проверкой

Вы говорите, что должно быть верно; TestSprite разбирается, как это проверить, и запускает проверку против вашего развёрнутого приложения. Этап перевода — та часть, которая никогда не была сутью, — исчезает.

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

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