У вас есть тестовая копия магазина, тестовый аккаунт и папка с тестами, и вы хотите убедиться, что вход в систему, добавление в корзину и оформление заказа работают после сегодняшнего обновления. Это автоматизированное тестирование в миниатюре: один сценарий, одна команда, один результат, который можно прочитать. FlowLatch открывает папку, запускает команду через Shell и показывает реальный код выхода на карточке. Если сценарий падает, он указывает на строку и предлагает исправление в виде diff, а вы решаете, принять его или нет. Ниже — 4 шага от папки к результату. Работайте только с приложением, которое вы разрабатываете или имеете право тестировать, используйте тестовый аккаунт и фейковые данные, а для шага оплаты включите тестовый режим вашей платежной системы, а не используйте реальную карту. Проверка почты идет в тестовый ящик, настроенный специально для тестов.
Запустите FlowLatch, выберите папку с тестами в качестве рабочей и выберите режим Ask first, чтобы каждое действие, изменяющее что-либо, ждало вашего подтверждения. Подключите модель, если еще не сделали этого, и используйте кнопку Test для проверки конечной точки.
Запросите структуру тестов. Команды list_dir и glob покажут файлы, а read_file откроет процесс оформления заказа, чтобы вы и агент начинали с одного текста до любых запусков или изменений. Каждое действие отображается в чате в виде карточки с результатом.
Сообщите агенту, какую команду теста использует ваш проект. Shell запустит ее в Windows или в WSL, а карточка покажет полный вывод и реальный код выхода, а не сводку. Раскройте карточку, если хотите увидеть каждую строку, и используйте grep в выводе, чтобы перейти к упавшему шагу.
При сбое спросите, что говорит вывод. Агент предложит редактирование в виде diff, и ничего не запишется, пока вы не примете его. Отклоните то, что выглядит неправильно, затем снова запустите команду, чтобы увидеть новый код выхода. Повторяйте, пока сценарий не пройдет или вы не поймете, что нужно изменить в приложении.
tests/перечисленоtests/checkout-flow-test.txtзагруженоyour test commandexit 0FAIL reports/0 совпадений# checkout flow for the staging copy of my shop
# uses only the test account and fake data
step 1: open the sign-in page
step 2: sign in with the test account
step 3: search for the sample product
step 4: add the sample product to the cart
step 5: open the cart and start checkout
step 6: pay in the test mode of my payment set-up
expect 1: the order confirmation page is shown
expect 2: the order list shows the new test order
expect 3: the test inbox received the confirmation
# when a step fails, save a screenshot and the page textЭта схема — обычный текст и лежит в репозитории рядом с вашими тестами. Ваша собственная тестовая система превращает каждый шаг в код, а FlowLatch использует файл как спецификацию, когда пишет этот код, запускает его и сравнивает результат с тремя строками expect. Измените название продукта и страницы, чтобы они соответствовали вашему тестовому приложению.
Начните с вопроса о том, где находятся тесты. list_dir покажет папки, glob перечислит все файлы, соответствующие шаблону, например, тесты оформления заказа, а read_file откроет те, которые вас интересуют, чтобы вы увидели, как сценарий устроен сегодня. Затем grep поищет селекторы и ожидания, которые они используют. Все это только чтение, поэтому это разумный первый шаг в режиме Plan only, который составляет план и ничего не запускает. План сохраняется после перезапуска, так что вы можете вернуться к нему завтра. Когда будете готовы к реальным запускам, переключитесь на Ask first и еще раз прочитайте план. Запишите сценарии, которые уже покрыты, чтобы знать, какие из них не имеют теста.
После обновления среды выполнения сбои в наборе e2e-тестов часто связаны с окружением, а не с вашим приложением, поэтому прочитайте первую ошибку, прежде чем трогать тест. Shell запустит вашу команду теста, а карточка сохранит полный вывод и реальный код выхода, который является единственным честным показателем успеха или неудачи. grep может выцепить упавший шаг из длинного лога. Запросите простое объяснение ошибки в чате, сравните его с выводом и только тогда решите, нужно ли редактировать файл теста. Если ошибка указывает на отсутствующий пакет или измененную настройку, сначала исправьте окружение и снова запустите ту же команду. Часто набор тестов проходит без каких-либо правок, и код выхода на карточке это доказывает.
Поддержка селекторов в ui-тестировании — самая распространенная рутина, потому что изменение макета ломает селекторы, связанные с ним. grep найдет старый селектор во всех файлах, read_file покажет шаги вокруг него, а edit_file предложит стабильную метку или test id вместо него. В режиме Ask first агент приостановится и покажет diff. Примите строки, которые выглядят правильно, затем дайте Shell снова запустить команду. Зеленый код выхода после редактирования — это результат, которого вы хотели, а diff останется в истории вашего репозитория для следующего ревьюера. Если команда все еще падает, прочитайте новый вывод, прежде чем просить еще одно изменение, потому что второе исправление поверх неверного предположения затрудняет понимание причины. Делайте каждый diff достаточно маленьким, чтобы его можно было прочитать за один присест.
Когда ui e2e-тест падает, реальной причиной часто является фиксированное ожидание, общие тестовые данные или порядок тестов, а не приложение. Попросите FlowLatch запустить упавший тест несколько раз с той же командой и сообщить о каждом коде выхода. Смешанные результаты означают, что тест нестабилен. Если ваш фреймворк сохранил скриншот, ocr прочитает текст на нем, а текст страницы из упавшего запуска добавит вторую подсказку. Исправьте ожидание или данные в diff, просмотрите его и снова запустите тест. Дайте каждому тесту свои данные и сбросьте их, дождитесь видимого условия вместо фиксированной паузы и держите тесты независимыми от порядка других тестов. Повторите запуск еще раз после исправления; один проход мало что доказывает.
