Mağazanızın bir staging kopyasına, bir test hesabına ve bir test klasörüne sahipsiniz; bugünkü değişiklikten sonra oturum açma, sepete ekleme ve checkout adımlarının hâlâ çalışıp çalışmadığını öğrenmek istiyorsunuz. Bu, otomatik web testinin en sade hâli: bir akış, bir test komutu, okunabilir bir sonuç. FlowLatch klasörü açar, komutu Shell aracılığıyla çalıştırır ve gerçek çıkış kodunu bir kart üzerinde gösterir. Akış başarısız olursa, sorumlu satırı işaret eder ve bir düzeltmeyi fark olarak önerir; kabul edip etmemek size kalır. Aşağıdaki adımlar, klasörden sonuca dört adımı kapsar. Yalnızca geliştirdiğiniz veya test etme yetkiniz olan uygulamalarda çalışın, test hesabını ve sahte verileri kullanın ve ödeme adımı için kendi ödeme kurulumunuzun test modunu kullanın, gerçek kart kullanmayın. E-posta kontrolleri, test için ayrılmış bir test posta kutusuna gider.
FlowLatch'i başlatın, testlerinizin bulunduğu klasörü çalışma klasörü olarak seçin ve her şeyi değiştiren eylemler için onayınızı bekleyen Ask first seçeneğini belirleyin. Henüz bağlamadıysanız bir model bağlayın ve Test düğmesiyle uç noktanın çalışıp çalışmadığını kontrol edin.
Testlerin yapısını öğren. list_dir ve glob dosyaları gösterir, read_file ise ödeme akışını açar; böylece hiçbir şey çalıştırılmadan veya değiştirilmeden önce sen ve agent aynı metinle başlarsın. Her eylem, sonucuyla birlikte sohbet penceresinde bir kart olarak görünür.
Ajanınıza projenizin hangi test komutunu kullandığını söyleyin. Shell komutu Windows'ta veya WSL'de çalıştırır; kart tam çıktıyı ve gerçek çıkış kodunu gösterir, özet değil. Her satırı görmek için kartı genişletin ve başarısız adıma atlamak için çıktıda grep kullanın.
Bir hata durumunda, çıktının ne dediğini sorun. Ajan bir edit önerisi olarak fark sunar, kabul edene kadar hiçbir şey yazılmaz. Yanlış görüneni reddedin, ardından komutu tekrar çalıştırarak yeni çıkış kodunu görün. Akış geçene kadar veya uygulamada neyi değiştireceğinizi bilene kadar tekrarlayın.
tests/listelenditests/checkout-flow-test.txtyüklenildiyour test commandexit 0FAIL reports/0 eşleşme# 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 textBu taslak düz metindir ve testlerinizin yanına depoda yer alır. Kendi test çerçeveniz her adımı koda dönüştürür; FlowLatch ise bu dosyayı, kodu yazarken, çalıştırırken ve sonucu üç beklenen satırla karşılaştırırken spesifikasyon olarak kullanır. Ürün adını ve sayfaları kendi staging uygulamanıza uygun şekilde değiştirin.
Önce testlerin nerede olduğunu sorun. list_dir klasörleri gösterir, glob checkout testleri gibi bir desene uyan tüm dosyaları listeler ve read_file ilgilendiğiniz dosyaları açar; böylece bir akışın bugünkü yapısını görebilirsiniz. grep ardından kullandıkları seçicileri ve bekleme mekanizmalarını arar. Bunların hepsi yalnızca okuma yaptığı için, Plan only modunda mantıklı bir ilk adımdır; bu mod bir plan yazar ve hiçbir şey çalıştırmaz. Plan bir yeniden başlatmada kaybolmaz, bu yüzden yarın geri dönebilirsiniz. Gerçek çalıştırmalara hazır olduğunuzda Ask first moduna geçin ve planı bir kez daha okuyun. Zaten testleri kapsayan akışları not edin, böylece hangilerinin test eksik olduğunu bilin.
Bir çalışma zamanı yükseltmesinden sonra, e2e paket hataları genellikle uygulamanızdan değil ortamdan kaynaklanır; bu yüzden bir testi değiştirmeden önce ilk hatayı okuyun. Shell test komutunuzu çalıştırır ve kart tam çıktıyı ile gerçek çıkış kodunu korur; bu, dürüst bir geçiş veya başarısızlık için tek yoldur. grep uzun bir girdiden başarısız adımı ayırabilir. Hata için sohbet penceresinde düz bir açıklama isteyin, çıktıyla karşılaştırın ve ancak o zaman bir test dosyasının düzenlenmesi gerekip gerekmediğine karar verin. Hata eksik bir paketi veya değişen bir ayarı belirtiyorsa, önce ortamı düzeltin ve aynı komutu tekrar çalıştırın. Sık sık paket, hiçbir düzenleme olmadan geçer ve karttaki çıkış kodu bunu kanıtlar.
ui test otomasyonunda seçici bakımı, değişen bir düzenin bağlı olduğu seçicileri bozduğu için en yaygın görevdir. grep eski seçiciyi tüm dosyalarda bulur, read_file etrafındaki adımları gösterir ve edit_file yerine kararlı bir etiket veya test kimliği önerir. Ask first modunda ajan durur ve farkı gösterir. Doğru görünen satırları kabul edin, ardından Shell'in komutu tekrar çalıştırmasına izin verin. Düzenlemeden sonra yeşil bir çıkış kodu, istediğiniz sonuçtur ve fark, sonraki gözden geçiren için depo geçmişinizde kalır. Komut hâlâ başarısız olursa, başka bir değişiklik istemeden önce yeni çıktıyı okuyun; yanlış bir tahminin üzerine yapılan ikinci bir düzenleme, nedeni görmeyi zorlaştırır. Her farkı, tek bir oturumda okunabilecek kadar küçük tutun.
Bir ui e2e testi kırıldığında, gerçek neden genellikle uygulama değil, sabit bir bekleme, paylaşılan test verileri veya testlerin sırasıdır. FlowLatch'ten aynı komutla başarısız testi birkaç kez çalıştırmasını ve her çıkış kodunu raporlamasını isteyin. Karışık sonuçlar, testin düzensiz (flaky) olduğunu gösterir. Çerçeveniz bir ekran görüntüsü kaydettiyse, ocr görüntüdeki metni okur ve başarısız çalıştırmanın sayfa metni ikinci bir ipucu sağlar. Beklemeyi veya veriyi bir farkta düzeltin, gözden geçirin ve testi tekrar çalıştırın. Her teste kendi verisini verin ve sıfırlayın, sabit bir duraklama yerine görünür bir koşul için bekleyin ve testleri birbirlerinin sırasından bağımsız tutun. Düzeltmeden sonra çalıştırmayı bir kez daha tekrarlayın; bir geçiş az şey kanıtlar.
