У вас є копія магазину на staging-сервері, тестовий обліковий запис і папка з тестами, і ви хочете дізнатися, чи працюють вхід, додавання до кошика та оформлення замовлення після сьогоднішніх змін. Це автоматизоване веб-тестування в мініатюрі: один потік, одна команда тестування, один результат, який ви можете прочитати. 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 використовує файл як специфікацію, коли він генерує цей код, запускає його та порівнює результат із трьома рядками очікувань. Змініть назву продукту та сторінки, щоб вони відповідали вашому власному staging-додатку.
Почніть із запиту, де знаходяться тести. 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, перегляньте його і запустіть тест знову. Надайте кожному тесту власні дані і скидайте їх, чекайте на видимий стан замість фіксованої паузи та робіть тести незалежними від порядку інших. Повторіть запуск ще раз після виправлення; один успішний запуск мало про що свідчить.
