Anda memiliki salinan staging toko, akun pengujian, dan folder berisi pengujian, dan ingin tahu apakah login, tambah ke keranjang, dan checkout masih berfungsi setelah perubahan hari ini. Ini adalah pengujian web otomatis dalam bentuk paling sederhana: satu alur, satu perintah pengujian, satu hasil yang bisa Anda baca. FlowLatch membuka folder, menjalankan perintah melalui Shell, dan menampilkan kode keluar asli pada kartu. Jika alur gagal, ia menunjuk ke baris tersebut dan mengusulkan perbaikan sebagai diff, lalu Anda memutuskan apakah akan menerimanya. Langkah-langkah di bawah ini membutuhkan 4 tindakan dari folder hingga hasil. Kerjakan hanya pada aplikasi yang Anda bangun atau berwenang untuk diuji, gunakan akun pengujian dan data palsu, serta gunakan mode pengujian dari pengaturan pembayaran Anda sendiri untuk langkah pembayaran, bukan kartu asli. Pemeriksaan email masuk ke kotak surat pengujian yang disiapkan khusus untuk pengujian.
Mulai FlowLatch, pilih folder yang berisi pengujian Anda sebagai folder kerja, dan pilih Ask first agar setiap tindakan yang mengubah sesuatu menunggu persetujuan Anda. Hubungkan model jika Anda belum melakukannya, dan gunakan tombol Test untuk memeriksa endpoint.
Tanyakan struktur pengujian. list_dir dan glob menampilkan file, dan read_file membuka alur checkout agar Anda dan agen memulai dari teks yang sama sebelum apa pun dijalankan atau diubah. Setiap tindakan muncul di obrolan sebagai kartu dengan hasilnya.
Beritahu agen perintah pengujian yang digunakan proyek Anda. Shell menjalankannya di Windows atau di WSL, dan kartu menampilkan output lengkap dan kode keluar asli, bukan ringkasan. Perluas kartu jika Anda ingin melihat setiap baris, dan gunakan grep pada output untuk melompat ke langkah yang gagal.
Saat terjadi kegagalan, tanyakan apa yang dikatakan output. Agen mengusulkan edit sebagai diff, dan tidak ada yang ditulis sampai Anda menerimanya. Tolak apa yang terlihat salah, lalu jalankan perintah lagi untuk melihat kode keluar baru. Ulangi hingga alur berhasil atau Anda tahu apa yang harus diubah di aplikasi.
tests/didaftarkantests/checkout-flow-test.txtdimuatyour test commandexit 0FAIL reports/0 kecocokan# 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 textKerangka ini adalah teks biasa dan berada di repositori di sebelah pengujian Anda. Framework pengujian Anda sendiri mengubah setiap langkah menjadi kode, dan FlowLatch menggunakan file sebagai spesifikasi saat menulis kode tersebut, menjalankannya, dan membandingkan hasilnya dengan tiga baris expect. Ubah nama produk dan halaman agar sesuai dengan aplikasi staging Anda sendiri.
Mulailah dengan bertanya di mana pengujian berada. list_dir menampilkan folder, glob mendaftarkan setiap file yang cocok dengan pola seperti pengujian checkout, dan read_file membuka file yang Anda pedulikan sehingga Anda bisa melihat bagaimana alur dibangun saat ini. grep kemudian mencari selector dan penunggu yang mereka gunakan. Semua ini hanya membaca, jadi ini adalah langkah pertama yang masuk akal dalam mode Plan only, yang membuat rencana dan tidak menjalankan apa pun. Rencana bertahan setelah restart, jadi Anda bisa kembali ke esok hari. Ketika Anda siap untuk menjalankan pengujian sungguhan, beralihlah ke Ask first dan baca rencana sekali lagi. Tuliskan alur yang sudah dicakup, sehingga Anda tahu mana yang belum memiliki pengujian.
Setelah peningkatan runtime, kegagalan suite e2e sering berasal dari lingkungan daripada dari aplikasi Anda, jadi baca kesalahan pertama sebelum Anda menyentuh pengujian. Shell menjalankan perintah pengujian Anda dan kartu menyimpan output lengkap dan kode keluar asli, yang merupakan lulus atau gagal yang paling jujur. grep bisa menarik langkah yang gagal dari log panjang. Minta penjelasan sederhana tentang kesalahan di obrolan, bandingkan dengan output, dan hanya kemudian putuskan apakah file pengujian perlu edit. Jika kesalahan menyebutkan paket yang hilang atau pengaturan yang berubah, perbaiki lingkungan terlebih dahulu dan jalankan perintah yang sama lagi. Seringkali suite kemudian berhasil tanpa edit sama sekali, dan kode keluar pada kartu membuktikannya.
Pemeliharaan selector dalam otomatisasi pengujian UI adalah tugas rutin yang paling umum, karena tata letak yang berubah merusak selector yang terkait dengannya. grep menemukan selector lama di setiap file, read_file menunjukkan langkah-langkah di sekitarnya, dan edit_file mengusulkan label stabil atau id pengujian sebagai gantinya. Dalam Ask first, agen berhenti dan menampilkan diff. Terima baris yang terlihat benar, lalu biarkan Shell menjalankan perintah lagi. Kode keluar hijau setelah edit adalah hasil yang Anda inginkan, dan diff tetap ada di riwayat repositori Anda untuk peninjau berikutnya. Jika perintah masih gagal, baca output baru sebelum Anda meminta perubahan lain, karena edit kedua di atas tebakan yang salah membuat penyebab lebih sulit dilihat. Jaga setiap diff cukup kecil untuk dibaca dalam satu sesi.
Ketika pengujian e2e UI rusak, penyebab sebenarnya sering kali adalah penunggu tetap, data pengujian bersama, atau urutan pengujian, bukan aplikasi. Minta FlowLatch menjalankan pengujian yang gagal beberapa kali dengan perintah yang sama dan laporkan setiap kode keluar. Hasil campuran berarti pengujian flaky. Jika framework Anda menyimpan tangkapan layar, ocr membaca teks di dalamnya, dan teks halaman dari run yang gagal menambahkan petunjuk kedua. Perbaiki penunggu atau data dalam diff, tinjau, dan jalankan pengujian lagi. Berikan setiap pengujian data sendiri dan atur ulang, tunggu kondisi yang terlihat daripada jeda tetap, dan jaga agar pengujian independen dari urutan satu sama lain. Ulangi run sekali lagi setelah perbaikan; satu kali lulus membuktikan sedikit.
