🏏 😻 🏟️ यूआई ऑटो-परीक्षण: यह कैसे करना है इसके लायक नहीं है 👩‍👧 ⚓️ 🆘

हेलो, हैबर। मेरा नाम विटालि कोटोव है, मैं परीक्षा विभाग में काम करता हूं। मैं बहुत सारे यूआई ऑटो-परीक्षण लिखता हूं, लेकिन मैं उन लोगों के साथ और भी अधिक काम करता हूं जो ऐसा बहुत पहले से कर रहे हैं और अभी तक सभी रेक पर कदम नहीं बढ़ा पाए हैं।

इसलिए, अपने अनुभव और अन्य लोगों की टिप्पणियों को जोड़कर, मैंने आपके लिए "कैसे परीक्षण लिखने के लिए लायक नहीं है" का एक संग्रह तैयार करने का फैसला किया। मैंने एक विस्तृत विवरण, कोड उदाहरण और स्क्रीनशॉट के साथ प्रत्येक उदाहरण का समर्थन किया।

यूआई परीक्षणों के लेखकों की शुरुआत के लिए लेख दिलचस्प होगा, लेकिन इस विषय में पुराने समय के लोग शायद कुछ नया सीखेंगे, या सिर्फ मुस्कुराएंगे, खुद को "अपनी युवावस्था में" याद रखेंगे। :)

चलो चलते हैं!

सामग्री

विशेषताओं के बिना लोकेटर

एक सरल उदाहरण से शुरू करते हैं। चूंकि हम UI परीक्षणों के बारे में बात कर रहे हैं, स्थानीय लोग उनमें एक महत्वपूर्ण भूमिका निभाते हैं। एक लोकेटर एक निश्चित नियम के अनुसार और एक या अधिक एक्सएमएल (विशेष रूप से HTML) तत्वों का वर्णन करने वाली एक पंक्ति है।

कई प्रकार के लोकेटर हैं। उदाहरण के लिए, सीएसएस लोकेटर का उपयोग कैस्केडिंग स्टाइल शीट के लिए किया जाता है। XPath लोकेटर का उपयोग XML दस्तावेजों के साथ काम करने के लिए किया जाता है। और इसी तरह।

सेलेनियम द्वारा उपयोग किए जाने वाले लोकेटर प्रकारों की एक पूरी सूची seleniumhq.imtqy.com पर देखी जा सकती है।

यूआई परीक्षणों में, उन तत्वों का वर्णन करने के लिए लोकेटर का उपयोग किया जाता है जिनके साथ चालक को बातचीत करनी चाहिए।

लगभग किसी भी ब्राउज़र इंस्पेक्टर में, हमारे लिए ब्याज के तत्व का चयन करना और उसके XPath को कॉपी करना संभव है। यह कुछ इस तरह दिखता है:

ऐसा पता चलता है:

/html/body/div[3]/div[1]/div[2]/div/div/div[2]/div[1]/a

ऐसा लगता है कि इस तरह के लोकेटर के साथ कुछ भी गलत नहीं है। आखिरकार, हम इसे कक्षा के कुछ स्थिर या क्षेत्र में सहेज सकते हैं, जो इसके नाम से तत्व का सार बताएगा:

 @FindBy(xpath = "/html/body/div[3]/div[1]/div[2]/div/div/div[2]/div[1]/a") public WebElement createAccountButton;

तत्व नहीं मिलने की स्थिति में संबंधित त्रुटि पाठ को लपेटें:

 public void waitForCreateAccountButton() { By by = By.xpath(this.createAccountButton); WebDriverWait wait = new WebDriverWait(driver, timeoutInSeconds); wait .withMessage(“Cannot find Create Account button.”) .until( ExpectedConditions.presenceOfElementLocated(by) ); }

इस दृष्टिकोण का एक प्लस है: XPath सीखने की कोई आवश्यकता नहीं है।

हालांकि, कई नुकसान हैं। सबसे पहले, लेआउट बदलते समय इस बात की कोई गारंटी नहीं है कि ऐसे लोकेटर पर तत्व समान रहेगा। यह संभव है कि कोई दूसरा अपना स्थान ले लेगा, जिससे अप्रत्याशित परिस्थितियां पैदा हो जाएंगी। दूसरे, ऑटोटेस्ट्स का कार्य बग्स की तलाश करना है, न कि लेआउट परिवर्तनों की निगरानी करना। इसलिए, कुछ रैपर या पेड़ में उच्चतर कुछ अन्य तत्वों के अलावा हमारे परीक्षणों को प्रभावित नहीं करना चाहिए। अन्यथा, हमें लोकेटर अपडेट करने में काफी समय लगेगा।

निष्कर्ष: आपको लोकेटर बनाना चाहिए जो तत्व का सही वर्णन करते हैं और हमारे आवेदन के परीक्षण किए गए भाग के बाहर लेआउट को बदलने के लिए प्रतिरोधी हैं। उदाहरण के लिए, आप किसी तत्व के एक या अधिक गुणों से बंध सकते हैं:

//a[@rel=”createAccount”]

इस तरह के एक लोकेटर को कोड में देखना आसान है, और यह केवल तभी टूटेगा जब "रिलीस" गायब हो जाएगा।

ऐसे लोकेटर का एक और प्लस निर्दिष्ट विशेषता के साथ टेम्पलेट रिपॉजिटरी में खोज करने की क्षमता है। लेकिन क्या देखने के लिए अगर लोकेटर मूल उदाहरण में दिखता है? :)

यदि शुरू में आवेदन में तत्वों की कोई विशेषता नहीं होती है या वे स्वचालित रूप से सेट हो जाते हैं (उदाहरण के लिए, कक्षाओं में बाधा के कारण), तो यह डेवलपर्स के साथ चर्चा के लायक है। उन्हें उत्पाद परीक्षण को स्वचालित करने में कोई कम दिलचस्पी नहीं होनी चाहिए और निश्चित रूप से आपसे मिलेंगे और एक समाधान पेश करेंगे।

लापता आइटम के लिए जाँच करें

प्रत्येक Badoo उपयोगकर्ता की अपनी प्रोफ़ाइल होती है। इसमें उपयोगकर्ता के बारे में जानकारी होती है: (नाम, आयु, फोटो) और इस बारे में जानकारी कि उपयोगकर्ता किसके साथ चैट करना चाहता है। इसके अलावा, अपनी रुचियों को इंगित करना संभव है।

मान लीजिए कि हमारे पास एक बार एक बग था (हालांकि, निश्चित रूप से, यह ऐसा नहीं है :))। उनकी प्रोफ़ाइल में उपयोगकर्ता ने रुचियों को चुना। सूची से उपयुक्त रुचि नहीं मिलने पर, उन्होंने सूची को अपडेट करने के लिए "अधिक" पर क्लिक करने का निर्णय लिया।

अपेक्षित व्यवहार: पुराने हित गायब होने चाहिए, नए दिखना चाहिए। लेकिन इसके बजाय "अनपेक्षित त्रुटि" पॉप अप हुई:

यह पता चला कि सर्वर साइड में कोई समस्या थी, उत्तर समान नहीं था, और क्लाइंट ने एक अधिसूचना दिखाकर इस मामले को संसाधित किया।

हमारा काम एक ऑटोटेस्ट लिखना है जो इस मामले की जांच करेगा।

हम लगभग निम्नलिखित स्क्रिप्ट लिखते हैं:

प्रोफ़ाइल खोलें
हितों की सूची खोलें
"अधिक" बटन पर क्लिक करें
सुनिश्चित करें कि त्रुटि दिखाई नहीं दी (उदाहरण के लिए, कोई div.error तत्व नहीं है)

हम ऐसी परीक्षा चलाते हैं। हालांकि, निम्नलिखित होता है: कुछ दिनों / महीनों / वर्षों के बाद, बग फिर से प्रकट होता है, हालांकि परीक्षण कुछ भी नहीं पकड़ता है। क्यों?

यह काफी सरल है: परीक्षण के सफल गुजरने के दौरान, हमने जिस तत्व को त्रुटि पाठ के लिए खोजा था उसका लोकेटर बदल गया है। टेम्प्लेटों का पुन: निर्धारण किया गया और "त्रुटि" वर्ग के बजाय हमें "error_new" वर्ग मिला।

रीफैक्टरिंग के दौरान, परीक्षण उम्मीद के मुताबिक काम करता रहा। Div.error तत्व दिखाई नहीं दिया; पतन का कोई कारण नहीं था। लेकिन अब "div.error" तत्व बिल्कुल भी मौजूद नहीं है - इसलिए, परीक्षण कभी भी विफल नहीं होगा, चाहे आवेदन में कुछ भी हो।

निष्कर्ष: सकारात्मक जांच के साथ इंटरफ़ेस की संचालन क्षमता का परीक्षण करना बेहतर है। हमारे उदाहरण में, हमें उम्मीद करनी चाहिए कि हितों की सूची बदल गई है।

ऐसी परिस्थितियाँ होती हैं जब एक नकारात्मक परीक्षा को एक सकारात्मक द्वारा प्रतिस्थापित नहीं किया जा सकता है। उदाहरण के लिए, किसी तत्व के साथ बातचीत करते समय, "अच्छी" स्थिति में कुछ भी नहीं होता है, और "खराब" स्थिति में एक त्रुटि दिखाई देती है। इस मामले में, आपको "खराब" परिदृश्य का अनुकरण करने और इस पर एक ऑटोटेस्ट लिखने का तरीका भी आना चाहिए। इस प्रकार, हम सत्यापित करते हैं कि त्रुटि तत्व नकारात्मक मामले में प्रकट होता है, और इस तरह हम लोकेटर की प्रासंगिकता की निगरानी करते हैं।

एक आइटम के लिए जाँच करें

यह कैसे सुनिश्चित करें कि इंटरफ़ेस के साथ परीक्षण इंटरैक्शन सफल रहा और सब कुछ काम करता है? यह इस इंटरफ़ेस में होने वाले परिवर्तनों में सबसे अधिक बार देखा जाता है।

एक उदाहरण पर विचार करें। आपको यह सुनिश्चित करने की आवश्यकता है कि संदेश भेजते समय यह चैट में दिखाई दे:

स्क्रिप्ट कुछ इस तरह दिखती है:

उपयोगकर्ता प्रोफ़ाइल खोलें
उसके साथ चैट खोलें
एक संदेश लिखें
भेजने के लिए
संदेश के प्रकट होने की प्रतीक्षा करें।

हम अपने परीक्षण में ऐसे परिदृश्य का वर्णन करते हैं। मान लीजिए कि एक चैट संदेश एक लोकेटर से मेल खाता है:

p.message_text

यह हम कैसे सत्यापित करते हैं कि तत्व प्रकट होता है:

 this.waitForPresence(By.css('p.message_text'), "Cannot find sent message.");

यदि हमारा इंतजार काम करता है, तो सब कुछ क्रम में है: चैट संदेश तैयार किए गए हैं।

जैसा कि आपने अनुमान लगाया होगा, थोड़ी देर के बाद, चैट संदेश भेजना बंद हो जाता है, लेकिन हमारा परीक्षण बिना किसी रुकावट के काम करता रहता है। चलो ठीक है।

यह पता चला है कि चैट में एक नया तत्व दिखाई देने से पहले दिन: कुछ पाठ जो उपयोगकर्ता को संदेश को उजागर करने के लिए संकेत देता है यदि यह अचानक नोट किया गया हो:

और, सबसे मज़ेदार, यह हमारे लोकेटर के अंतर्गत भी आता है। केवल इसमें एक अतिरिक्त वर्ग है जो इसे भेजे गए संदेशों से अलग करता है:

p.message_text.highlight

जब यह ब्लॉक दिखाई दिया, तो हमारा परीक्षण नहीं टूटा, लेकिन चेक "संदेश के प्रकट होने की प्रतीक्षा करें" प्रासंगिक होना बंद हो गया। वह तत्व जो एक सफल घटना का सूचक था, अब हमेशा मौजूद है।

निष्कर्ष: यदि परीक्षण का तर्क कुछ तत्व की उपस्थिति की जांच पर आधारित है, तो यह जांचना आवश्यक है कि UI के साथ हमारी बातचीत से पहले ऐसा कोई तत्व नहीं है।

उपयोगकर्ता प्रोफ़ाइल खोलें
उसके साथ चैट खोलें
सुनिश्चित करें कि कोई भेजे गए संदेश नहीं हैं
एक संदेश लिखें
भेजने के लिए
संदेश के प्रकट होने की प्रतीक्षा करें।

रैंडम डेटा

अक्सर, यूआई परीक्षण उन रूपों के साथ काम करते हैं जिनमें वे डेटा दर्ज करते हैं। उदाहरण के लिए, हमारे पास पंजीकरण फॉर्म है:

ऐसे परीक्षणों के लिए डेटा को एक परीक्षण में कॉन्फ़िगर या हार्डकोड में संग्रहीत किया जा सकता है। लेकिन कभी-कभी यह विचार दिमाग में आता है: डेटा को यादृच्छिक क्यों नहीं? यह अच्छा है, हम अधिक मामलों को कवर करेंगे!

मेरी सलाह: नहीं। और अब मैं आपको बताता हूँ कि क्यों।

मान लीजिए हमारा टेस्ट Badoo पर पंजीकृत है। हम तय करते हैं कि हम उपयोगकर्ता के लिंग को यादृच्छिक रूप से चुनेंगे। परीक्षण लिखने के समय, लड़की के लिए और लड़के के लिए पंजीकरण का प्रवाह अलग नहीं है, इसलिए हमारा परीक्षण सफलतापूर्वक गुजरता है।

अब कल्पना करें कि थोड़ी देर बाद पंजीकरण का प्रवाह अलग हो जाता है। उदाहरण के लिए, हम लड़की को पंजीकरण के तुरंत बाद मुफ्त बोनस देते हैं, जिसके बारे में हम उसे एक विशेष ओवरले के साथ सूचित करते हैं।

परीक्षण में, ओवरले को बंद करने के लिए कोई तर्क नहीं है, लेकिन यह बदले में, परीक्षण में निर्धारित किसी भी आगे की कार्रवाई के साथ हस्तक्षेप करता है। हमें एक परीक्षण मिलता है जो 50% मामलों में आता है। कोई भी स्वचालन उपकरण पुष्टि करेगा कि UI परीक्षण स्वाभाविक रूप से स्थिर नहीं हैं। और यह सामान्य है, किसी को इसके साथ रहना पड़ता है, निरर्थक तर्क के बीच लगातार "सभी अवसरों के लिए" (जो कोड की पठनीयता को खराब करता है और इसके समर्थन को जटिल करता है) और इस अस्थिरता के बीच लगातार व्यवहार करता है।

अगली बार, जब परीक्षा होगी, तो हमारे पास इससे निपटने का समय नहीं हो सकता है। हम इसे पुनः आरंभ करते हैं और देखते हैं कि यह बीत चुका है। हम तय करते हैं कि हमारे आवेदन में सब कुछ उसी तरह काम करता है जैसा कि होना चाहिए और बात एक अस्थिर परीक्षण की है। और शांत हो जाओ।

अब आगे बढ़ते हैं। यदि यह ओवरले टूट जाता है तो क्या होगा? परीक्षण 50% मामलों में पास करना जारी रखेगा, जो समस्या को खोजने में काफी देरी करता है।

और यह अच्छा है, जब डेटा के यादृच्छिककरण के कारण, हम "50 बाय 50" स्थिति बनाते हैं। लेकिन यह अलग तरह से होता है। उदाहरण के लिए, पंजीकरण से पहले, एक पासवर्ड को लंबाई में कम से कम तीन वर्णों के लिए स्वीकार्य माना जाता था। हम कोड लिखते हैं जो एक यादृच्छिक पासवर्ड के साथ आता है जो तीन अक्षरों (कभी-कभी तीन वर्णों, और कभी-कभी अधिक) से कम नहीं होता है। और फिर नियम बदल जाता है - और पासवर्ड में पहले से ही कम से कम चार अक्षर होने चाहिए। इस मामले में गिरावट की संभावना क्या है? और, अगर हमारा परीक्षण एक वास्तविक बग को पकड़ता है, तो हम कितनी जल्दी इसका पता लगाएंगे?

ऐसे परीक्षणों के साथ काम करना विशेष रूप से मुश्किल है जहां बहुत सारे यादृच्छिक डेटा दर्ज किए जाते हैं: नाम, लिंग, पासवर्ड, और इसी तरह ... इस मामले में, कई अलग-अलग संयोजन भी हैं, और यदि उनमें से किसी में कोई त्रुटि होती है, तो आमतौर पर नोटिस करना मुश्किल होता है।

निष्कर्ष। जैसा कि मैंने ऊपर लिखा था, डेटा यादृच्छिक करना खराब है। समकक्ष वर्गों के बारे में भूलकर, डेटा प्रदाताओं की कीमत पर अधिक मामलों को कवर करना बेहतर है। परीक्षा पास करने में अधिक समय लगेगा, लेकिन आप इससे लड़ सकते हैं। लेकिन हमें यकीन होगा कि अगर कोई समस्या है, तो इसका पता लगाया जाएगा।

परीक्षणों की परमाणु (भाग 1)

आइए निम्नलिखित उदाहरण देखें। हम एक परीक्षण लिख रहे हैं जो पाद लेख में उपयोगकर्ताओं के काउंटर की जांच करता है।

परिदृश्य सरल है:

एप्लिकेशन खोलें
पाद काउंटर खोजें
सुनिश्चित करें कि यह दिखाई दे रहा है

हम इस तरह के एक परीक्षण testFooterCounter कहते हैं और इसे चलाते हैं। फिर यह जांचना आवश्यक हो जाता है कि काउंटर शून्य नहीं दिखाता है। हम इस परीक्षण को मौजूदा परीक्षण में जोड़ते हैं, क्यों नहीं?

लेकिन फिर यह सत्यापित करना आवश्यक हो जाता है कि पाद लेख में परियोजना के विवरण के लिए एक लिंक है (लिंक "हमारे बारे में")। एक नया परीक्षण लिखें या मौजूदा में जोड़ें? एक नए परीक्षण के मामले में, हमें आवेदन को फिर से बढ़ाना होगा, उपयोगकर्ता को तैयार करना होगा (यदि हम अधिकृत पृष्ठ पर पाद की जांच करते हैं), सामान्य रूप से लॉग इन करें - कीमती समय व्यतीत करें। ऐसी स्थिति में, TestFooterCounterAndLinks का नाम बदलना एक अच्छे विचार की तरह लगता है।

एक तरफ, इस दृष्टिकोण के फायदे हैं: समय की बचत, हमारे आवेदन के कुछ हिस्से (इस मामले में, पाद लेख) के सभी चेक को एक स्थान पर संग्रहीत करना।

लेकिन ध्यान देने योग्य माइनस है। यदि परीक्षण पहले परीक्षण में विफल रहता है, तो हम बाकी घटक की जांच नहीं करेंगे। मान लीजिए कि अस्थिरता के कारण नहीं, बल्कि बग के कारण किसी शाखा में परीक्षण क्रैश हो जाता है। क्या करें? केवल इस समस्या का वर्णन करते हुए कोई कार्य लौटाएँ? फिर हम केवल इस बग को ठीक करने के साथ एक कार्य प्राप्त करने का जोखिम चलाते हैं, एक परीक्षण चलाते हैं और यह पता लगाते हैं कि घटक आगे भी टूट गया है, दूसरी जगह पर। और ऐसे कई पुनरावृत्तियों हो सकते हैं। इस मामले में आगे और पीछे एक टिकट मारना बहुत समय लगेगा और अप्रभावी होगा।

निष्कर्ष: यदि संभव हो तो, चेक को एटमाइज़ करें। इस मामले में, यहां तक कि एक मामले में समस्या होने पर, हम अन्य सभी की जांच करेंगे। और, यदि आपको टिकट वापस करना है, तो हम तुरंत सभी समस्या क्षेत्रों का वर्णन कर सकते हैं।

परीक्षणों की परमाणुता (भाग 2)

एक अन्य उदाहरण पर विचार करें। हम एक चैट टेस्ट लिख रहे हैं जो निम्नलिखित तर्क की जाँच करता है। यदि उपयोगकर्ताओं में आपसी सहानुभूति है, तो चैट में निम्न प्रोमोलॉक दिखाई देता है:

परिदृश्य इस प्रकार है:

उपयोगकर्ता B के लिए उपयोगकर्ता A द्वारा वोट करें
उपयोगकर्ता A के लिए उपयोगकर्ता B द्वारा वोट करें
उपयोगकर्ता B उपयोगकर्ता के साथ एक खुली चैट करता है
पुष्टि करें कि इकाई जगह में है

कुछ समय के लिए, परीक्षण सफलतापूर्वक काम करता है, लेकिन फिर निम्नलिखित होता है ... नहीं, इस बार परीक्षण किसी भी बग को याद नहीं करता है। :)

कुछ समय बाद, हमें पता चलता है कि हमारे परीक्षण से संबंधित एक और बग नहीं है: यदि आप एक चैट खोलते हैं, तो तुरंत इसे बंद करें और इसे फिर से खोलें, ब्लॉक गायब हो जाता है। सबसे स्पष्ट मामला नहीं है, और परीक्षण में, निश्चित रूप से, हमने इसका पूर्वाभास नहीं किया। लेकिन हम तय करते हैं कि हमें इसे भी कवर करने की जरूरत है।

एक ही सवाल उठता है: एक और परीक्षण लिखें या एक मौजूदा एक परीक्षण डालें? एक नया लिखना अनुचित लगता है, क्योंकि 99% समय वह मौजूदा के समान ही करेगा। और हम परीक्षण को उस परीक्षण में जोड़ने का निर्णय लेते हैं जो पहले से ही है:

उपयोगकर्ता B के लिए उपयोगकर्ता A द्वारा वोट करें
उपयोगकर्ता A के लिए उपयोगकर्ता B द्वारा वोट करें
उपयोगकर्ता A उपयोगकर्ता B के साथ एक खुली बातचीत करता है
पुष्टि करें कि इकाई जगह में है
चैट बंद करें
चैट खोलें
पुष्टि करें कि इकाई जगह में है

एक समस्या सामने आ सकती है, उदाहरण के लिए, हम लंबे समय के बाद एक परीक्षण को रिफ्लेक्टर करते हैं। उदाहरण के लिए, एक परियोजना पर एक नया स्वरूप होगा - और आपको बहुत सारे परीक्षणों को फिर से लिखना होगा।

हम परीक्षण खोलेंगे और यह याद रखने की कोशिश करेंगे कि यह क्या जाँच करता है। उदाहरण के लिए, किसी परीक्षण को testPromoAfterMutualAttraction कहा जाता है। क्या हम समझते हैं कि चैट का उद्घाटन और समापन अंत में क्यों लिखा गया है? सबसे अधिक संभावना नहीं है। खासकर अगर यह परीक्षा हमारे द्वारा नहीं लिखी गई थी। क्या हम इस टुकड़े को छोड़ देंगे? शायद हां, लेकिन अगर उसके साथ कोई समस्या है, तो संभावना है कि हम उसे बस हटा देंगे। और सत्यापन केवल इसलिए खो जाएगा क्योंकि इसका अर्थ स्पष्ट नहीं होगा।

मैं यहां दो समाधान देखता हूं। पहला: अभी भी दूसरा परीक्षण करते हैं और इसे testCheckBlockPresentAfterOpenAndCloseChat कहते हैं। इस तरह के नाम के साथ, यह स्पष्ट होगा कि हम सिर्फ एक निश्चित कार्रवाई नहीं कर रहे हैं, बल्कि एक बहुत सचेत जांच कर रहे हैं, क्योंकि एक नकारात्मक अनुभव था। दूसरा उपाय इस कोड में एक विस्तृत टिप्पणी लिखना है कि हम इस विशेष परीक्षण में यह परीक्षण क्यों कर रहे हैं। टिप्पणी में बग संख्या को इंगित करना भी उचित है।

मौजूदा आइटम पर क्लिक करने में त्रुटि

निम्नलिखित उदाहरण ने मेरे लिए bbidox फेंक दिया, जिसके लिए वह कर्म में एक बड़ा धन है!

एक बहुत ही दिलचस्प स्थिति है जब परीक्षण कोड पहले से ही हो जाता है ... एक रूपरेखा। मान लीजिए कि हमारे पास एक तरीका है:

  public void clickSomeButton() { WebElement button_element = this.waitForButtonToAppear(); button_element.click(); }

कुछ बिंदु पर, इस पद्धति से कुछ अजीब होने लगता है: जब आप एक बटन पर क्लिक करने का प्रयास करते हैं तो परीक्षण क्रैश हो जाता है। हम परीक्षण के दुर्घटनाग्रस्त होने के समय लिया गया स्क्रीनशॉट खोलते हैं, और हम देखते हैं कि स्क्रीनशॉट में एक बटन है और WaitForButtonToAppear विधि ने सफलतापूर्वक काम किया है। प्रश्न: क्लिक में क्या गलत है?

इस स्थिति में सबसे कठिन हिस्सा यह है कि परीक्षण कभी-कभी सफल हो सकता है। :)

चलो ठीक है। मान लीजिए कि उदाहरण में माना गया बटन इस तरह के ओवरले पर स्थित है:

यह एक विशेष ओवरले है जिसके माध्यम से हमारी वेबसाइट पर एक उपयोगकर्ता अपने बारे में जानकारी भर सकता है। जब आप हाइलाइट किए गए ओवरले बटन पर क्लिक करते हैं, तो अगला ब्लॉक फिल होता है।

मनोरंजन के लिए, आइए इस बटन के लिए एक अतिरिक्त OLOLO वर्ग जोड़ें:

जिसके बाद हम इस बटन पर क्लिक करते हैं। नेत्रहीन, कुछ भी नहीं बदला है, लेकिन बटन ही जगह पर बना हुआ है:

क्या हुआ था? वास्तव में, जब जेएस ने हमारे लिए ब्लॉक को फिर से तैयार किया, उसने बटन को भी फिर से तैयार किया। यह अभी भी एक ही लोकेटर पर उपलब्ध है, लेकिन यह एक और बटन है। यह OLOLO वर्ग की कमी से स्पष्ट है जो हमने जोड़ा था।

उपरोक्त कोड में, हम तत्व को $ तत्व चर में संग्रहीत करते हैं। यदि इस दौरान कोई तत्व पुनर्जीवित होता है, तो वह नेत्रहीन दिखाई नहीं दे सकता है, लेकिन आप अब उस पर क्लिक नहीं कर सकते - क्लिक () विधि विफल हो जाएगी।

कई समाधान हैं:

कोशिश ब्लॉक में क्लिक करें और पुनः निर्माण तत्व को पकड़ें
एक बटन को विशेषता में जोड़ने के लिए संकेत दें कि यह बदल गया है

त्रुटि पाठ

अंत में, एक सरल, लेकिन कोई कम महत्वपूर्ण बिंदु नहीं।

यह उदाहरण न केवल UI परीक्षणों पर लागू होता है, बल्कि उनमें बहुत बार होता है। आमतौर पर, जब आप एक परीक्षा लिखते हैं, तो आप इस संदर्भ में होते हैं कि क्या हो रहा है: आप सत्यापन के बाद सत्यापन का वर्णन करते हैं और उनका अर्थ समझते हैं। और आप एक ही संदर्भ में त्रुटि ग्रंथ लिखते हैं:

 WebElement element = this.waitForPresence(By.css("a.link"), "Cannot find button");

इस कोड में क्या समझ से बाहर हो सकता है? परीक्षण एक बटन की उपस्थिति की उम्मीद करता है और, अगर यह नहीं है, तो स्वाभाविक रूप से गिरता है।

अब कल्पना करें कि परीक्षण के लेखक बीमार छुट्टी पर हैं, और उनके सहयोगी परीक्षणों की देखरेख कर रहे हैं। और फिर वह testQuestionsOnProfile का परीक्षण छोड़ देता है और यह संदेश लिखता है: "बटन नहीं खोज सकता"। एक सहकर्मी को यह समझने की आवश्यकता है कि जितनी जल्दी हो सके, क्योंकि रिलीज जल्द ही हो रही है।

उसे क्या करना होगा?

उस पृष्ठ को खोलना व्यर्थ है जिस पर परीक्षण गिर गया और "a.link" लोकेटर की जाँच करें - कोई तत्व नहीं है। इसलिए, आपको सावधानीपूर्वक परीक्षण का अध्ययन करना होगा और यह पता लगाना होगा कि यह क्या जांचता है।

यह अधिक विस्तृत त्रुटि पाठ के साथ बहुत सरल होगा: "प्रश्नों के ओवरले पर सबमिट बटन नहीं खोज सकते हैं"। ऐसी त्रुटि के साथ, आप तुरंत ओवरले को खोल सकते हैं और देख सकते हैं कि बटन कहां गया।

आउटपुट दो। सबसे पहले, यह आपके परीक्षण ढांचे के किसी भी तरीके से त्रुटि पाठ को पारित करने के लायक है, और यह एक आवश्यक पैरामीटर है ताकि इसके बारे में भूल जाने का कोई प्रलोभन न हो। दूसरे, त्रुटि पाठ को विस्तृत बनाया जाना चाहिए। इसका हमेशा यह मतलब नहीं है कि यह लंबा होना चाहिए, यह इस पर स्पष्ट करने के लिए पर्याप्त है कि परीक्षण में क्या गलत हुआ।

कैसे समझें कि त्रुटि पाठ अच्छी तरह से लिखा गया है? बहुत सरल है। कल्पना करें कि आपका एप्लिकेशन टूट गया है और आपको डेवलपर्स के पास जाने और समझाने की जरूरत है कि क्या और कहां टूट गया। यदि आप उन्हें केवल वही बताते हैं जो त्रुटि पाठ में लिखा गया है, तो क्या वे समझेंगे?

परिणाम

टेस्ट स्क्रिप्ट लिखना अक्सर एक दिलचस्प गतिविधि होती है। साथ ही हम कई लक्ष्यों का पीछा करते हैं। हमारे परीक्षण चाहिए:

अधिक से अधिक मामलों को कवर करें
जितनी जल्दी हो सके काम करें
समझा जाना
बस विस्तार करें
बनाए रखना आसान है
पिज्जा ऑर्डर करें
और इसी तरह ...

लगातार विकसित और बदलते प्रोजेक्ट में परीक्षणों के साथ काम करना विशेष रूप से दिलचस्प है, जहां उन्हें लगातार अपडेट किया जाना है: कुछ जोड़ें और कुछ काट लें। यही कारण है कि अग्रिम में कुछ बिंदुओं पर सोचने के लिए और हमेशा निर्णयों के साथ जल्दी करने के लिए सार्थक नहीं है। :)

मुझे उम्मीद है कि मेरी युक्तियां आपको कुछ समस्याओं से बचने में मदद करेंगी और केस स्टडी में आपको अधिक विचारशील बनाएंगी। अगर दर्शकों को लेख पसंद आया, तो मैं कुछ और उबाऊ उदाहरणों को इकट्ठा करने की कोशिश करूंगा। इस बीच में - अलविदा!

यूआई ऑटो-परीक्षण: यह कैसे करना है इसके लायक नहीं है