Баги в коде Lovable: как проверить приложение, которое вы не писали

Честная отправная точка

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

Где обычно прячутся баги в коде Lovable

Сгенерированные приложения ломаются в предсказуемом порядке. Начните с этого.

Проверка, которая продолжает работать

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

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

Всё это доступно и в дашборде TestSprite — обычно это более удобный путь, если вы работаете не в терминале. Подробности о CLI — в репозитории CLI.

Три проверки, которые стоит завести с первого дня

• Зарегистрируйтесь, а затем войдите снова. Здесь сгенерированные приложения ломаются чаще, чем где-либо ещё, и именно с этого начинает реальный пользователь.

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

• Сделайте то единственное, ради чего существует ваше приложение, — под совершенно новой учётной записью. Если у постороннего человека это работает, у вас уже что-то есть.

Как описать баг, чтобы исправление действительно попало в цель

Когда что-то не так, первое желание — написать «это сломано». Агенту это даёт очень мало, и в ответ вы получите правку, которая чинит что-то соседнее.

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

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

В каком порядке проверять

Есть последовательность, которая находит проблемы быстрее, чем бессистемные клики, и занимает она около десяти минут.

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

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

Когда вы готовы показать приложение другим

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

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

Как TestSprite проверяет за вас

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

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

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