आपके पास आपके शॉप की एक स्टैगिंग कॉपी, एक टेस्ट अकाउंट और टेस्ट्स का एक फोल्डर है, और आप जानना चाहते हैं कि आज के बदलाव के बाद साइन इन, कार्ट में जोड़ना और चेकआउट अभी भी काम कर रहे हैं या नहीं। यह सबसे छोटे स्तर पर ऑटोमेटेड वेब टेस्टिंग है: एक फ्लो, एक टेस्ट कमांड, और एक रिजल्ट जिसे आप पढ़ सकते हैं। FlowLatch फोल्डर खोलता है, कमांड को Shell के माध्यम से चलाता है और एक कार्ड पर असली एग्जिट कोड दिखाता है। यदि फ्लो फेल होता है, तो यह लाइन की ओर इशारा करता है और एक डिफ के रूप में फिक्स का प्रस्ताव देता है, और आप तय करते हैं कि उसे स्वीकार करना है या नहीं। नीचे दिए गए चरण फोल्डर से रिजल्ट तक 4 एक्शन लेते हैं। केवल उसी ऐप पर काम करें जिसे आप बना रहे हैं या टेस्ट करने के लिए अधिकृत हैं, टेस्ट अकाउंट और फेक डेटा का उपयोग करें, और पेमेंट स्टेप के लिए अपने ऑनलाइन पेमेंट सेटअप के टेस्ट मोड का उपयोग करें, कभी भी असली कार्ड का उपयोग न करें। ईमेल चेक टेस्ट के लिए सेटअप किए गए टेस्ट इनबॉक्स में जाते हैं।
FlowLatch शुरू करें, अपने टेस्ट्स को रखने वाले फोल्डर को वर्किंग फोल्डर के रूप में चुनें, और 'Ask first' चुनें ताकि हर एक्शन जो कुछ बदलता है, आपके OK का इंतजार करे। यदि आपने अभी तक कनेक्ट नहीं किया है, तो एक मॉड कनेक्ट करें, और एंडपॉइंट की जांच के लिए टेस्ट बटन का उपयोग करें।
टेस्ट की संरचना का प्रश्न पूछें। list_dir और glob फ़ाइलों को दिखाते हैं, और read_file चेकआउट फ़्लो खोलता है ताकि आप और एजेंट कुछ भी चलाने या बदलने से पहले एक ही टेक्स्ट से शुरू कर सकें। प्रत्येक क्रिया अपने परिणाम के साथ चैट में कार्ड के रूप में दिखाई देती है।
एजेंट को बताएं कि आपका प्रोजेक्ट कौन सा टेस्ट कमांड उपयोग करता है। Shell इसे Windows या WSL पर चलाता है, और कार्ड पूरा आउटपुट और असली एग्जिट कोड दिखाता है, न कि सारांश। यदि आप हर लाइन देखना चाहते हैं तो कार्ड को एक्सपैंड करें, और फेलिंग स्टेप पर जाने के लिए आउटपुट पर grep का उपयोग करें।
फेलियर पर, पूछें कि आउटपुट क्या कहता है। एजेंट एक डिफ के रूप में एडिट का प्रस्ताव देता है, और जब तक आप इसे स्वीकार नहीं करते, कुछ भी लिखा नहीं जाता है। जो गलत लगता है उसे रिजेक्ट करें, फिर नए एग्जिट कोड देखने के लिए कमांड को फिर से चलाएं। फ्लो पास होने तक या आपको यह पता लगने तक कि ऐप में क्या बदलना है, इसे दोहराएं।
tests/सूचीबद्धtests/checkout-flow-test.txtलोड किया गयाyour test commandएग्जिट 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 उस फाइल को स्पेसिफिकेशन के रूप में उपयोग करता है जब वह उस कोड को लिखता है, उसे चलाता है और रिजल्ट को तीन एक्सपेक्ट लाइनों से तुलना करता है। उत्पाद के नाम और पेजों को अपने स्टैगिंग ऐप से मेल खाने के लिए बदलें।
पहले यह पूछकर शुरू करें कि टेस्ट्स कहाँ हैं। list_dir फोल्डर दिखाता है, glob हर फाइल की सूची बनाता है जो एक पैटर्न जैसे कि चेकआउट टेस्ट्स से मेल खाती है, और read_file उन फाइलों को खोलता है जिनकी आपको परवाह है ताकि आप देख सकें कि आज एक फ्लो कैसे बनाया गया है। grep फिर उन सिलेक्टर्स और वेइट्स की खोज करता है जो वे उपयोग करते हैं। यह सब केवल पढ़ता है, इसलिए यह Plan only मोड में एक समझदारी भरा पहला कदम है, जो एक प्लान बनाता है और कुछ भी नहीं चलाता। प्लान एक रीस्टार्ट के बाद भी बरकरार रहता है, इसलिए आप कल वापस आ सकते हैं। जब आप असली रन्स के लिए तैयार हों, तो Ask first पर स्विच करें और प्लान को एक बार फिर पढ़ें। उन फ्लो को नोट करें जो पहले से कवर किए गए हैं, ताकि आपको पता चले कि किसमें टेस्ट की कमी है।
रनटाइम अपग्रेड के बाद, e2e सूट फेलियर अक्सर आपके ऐप के बजाय एनवायरनमेंट से आते हैं, इसलिए टेस्ट को छूने से पहले पहली एरर पढ़ें। Shell आपका टेस्ट कमांड चलाता है और कार्ड पूरा आउटपुट और असली एग्जिट कोड रखता है, जो ईमानदार पास या फेल का एकमात्र साबित है। grep एक लॉग से फेलिंग स्टेप को बाहर निकाल सकता है। चैट में एरर की एक साधारण व्याख्या के लिए पूछें, इसे आउटपुट से तुलना करें, और तभी तय करें कि क्या टेस्ट फाइल में एडिट की जरूरत है। यदि एरर किसी माइसिंग पैकेज या बदले सेटिंग का नाम बताती है, तो पहले एनवायरनमेंट को फिक्स करें और उसी कमांड को फिर से चलाएं। अक्सर सूट बिना किसी एडिट के पास हो जाता है, और कार्ड पर एग्जिट कोड इसे साबित करता है।
ui टेस्ट ऑटोमेशन में सिलेक्टर मेंटेनेंस सबसे आम चोर है, क्योंकि एक बदला हुआ लेआउट सिलेक्टर्स को तोड़ देता है जो उससे जुड़े हुए थे। grep हर फाइल में पुराना सिलेक्टर खोजता है, read_file उसके आसपास के स्टेप्स दिखाता है और edit_file एक स्थिर लेबल या टेस्ट आईडी का प्रस्ताव देता है। Ask first में एजेंट रुक जाता है और डिफ दिखाता है। जो लाइनें सही लगती हैं उन्हें स्वीकार करें, फिर Shell को कमांड फिर से चलाने दें। एडिट के बाद एक ग्रीन एग्जिट कोड वही रिजल्ट है जो आप चाहते थे, और डिफ अगले रिव्यूअर के लिए आपके रिपॉजिटरी इतिहास में बना रहता है। यदि कमांड अभी भी फेल होता है, तो एक और बदलाव मांगने से पहले नए आउटपुट को पढ़ें, क्योंकि एक गलत अनुमान के ऊपर दूसरा एडिट कारण को देखना मुश्किल बना देता है। हर डिफ को इतना छोटा रखें कि उसे एक बैठक में पढ़ा जा सके।
जब एक ui e2e टेट टूट जाता है, तो असली कारण अक्सर एक फिक्स्ड वेट, शेयर टेस्ट डेटा या टेस्ट्स का ऑर्डर होता है, न कि ऐप। FlowLatch से पूछें कि वह फेलिंग टेस्ट को एक ही कमांड के साथ कई बार चलाए और हर एग्जिट कोड रिपोर्ट करे। मिक्स्ड रिजल्ट्स का मतलब है कि टेस्ट फ्लैकी है। यदि आपके फ्रेमवर्क ने एक स्क्रीनशॉट सेव किया था, तो ocr उसमें टेक्स्ट पढ़ता है, और फेल रन से पेज टेक्स्ट एक दूसरा क्लू जोड़ता है। वेट या डेटा को एक डिफ में फिक्स करें, उसे रिव्यू करें, और टेस्ट को फिर से चलाएं। हर टेस्ट को उसका अपना डेटा दें और उसे रीसेट करें, फिक्स्ड पॉज के बजाय एक विजिबल कंडीशन के लिए वेट करें, और टेस्ट्स को एक-दूसरे के ऑर्डर से स्वतंत्र रखें। फिक्स के बाद रन को एक बार फिर दोहराएं; एक पास कम है।
