सेलेनियम WebDriverWait की उपयुक्तता के बारे में

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

इस लेख में मैं एक पृष्ठ पर एक घटना की प्रतीक्षा करने के लिए अक्सर उपयोग किए जाने वाले टूल पर चर्चा करना चाहता हूं, जिसे WebDriverWait वर्ग और उसके मुख्य तक विधि का उपयोग करके लागू किया गया है। मुझे आश्चर्य है कि अगर WebDriverWait की आवश्यकता है, और क्या इसे मना करना संभव है?

विचार सी # के संदर्भ में प्रस्तुत किए जाएंगे, हालांकि मुझे नहीं लगता कि इस वर्ग का कार्यान्वयन तर्क अन्य प्रोग्रामिंग भाषाओं के लिए अलग होगा।

WebDriverWait का एक उदाहरण बनाते समय, ड्राइवर का उदाहरण कंस्ट्रक्टर को दिया जाता है, जिसे आंतरिक इनपुट फ़ील्ड में संग्रहीत किया जाता है। जब तक विधि एक प्रतिनिधि को मान लेती है जिसका इनपुट पैरामीटर IWebDriver होना चाहिए, जिसमें से इनपुट एक उदाहरण है।

आइए, जब तक विधि का स्रोत कोड देखें। उसके तर्क की रीढ़ एक अंतहीन चक्र है जिसमें इसे बाहर निकालने के लिए दो शर्तें हैं: वांछित घटना की शुरुआत या समयबाह्य। अतिरिक्त "उपहार" पूर्वनिर्धारित अपवादों को अनदेखा कर रहे हैं और ऑब्जेक्ट वापस कर रहे हैं यदि ट्रॉस्लेट बूल नहीं है (उस पर बाद में अधिक)।

पहली सीमा जो मैं देख रहा हूं कि हमें हमेशा IWebDriver के एक उदाहरण की आवश्यकता है, हालांकि जब तक कि विधि के अंदर (सटीक होने के लिए, शर्त के लिए एक इनपुट पैरामीटर के रूप में) हम पूरी तरह से ISearchContext का प्रबंधन कर सकते हैं। दरअसल, ज्यादातर मामलों में, हम कुछ तत्व या इसकी संपत्ति में बदलाव की उम्मीद करते हैं और इसे खोजने के लिए FindElement (एस) का उपयोग करते हैं।

मैं यह कहने के लिए उद्यम करूंगा कि ISearchContext का उपयोग करना और भी अधिक तर्कसंगत होगा, क्योंकि क्लाइंट कोड (क्लास) केवल एक पेज ऑब्जेक्ट नहीं है, जो कि बच्चों की खोज में, पेज की जड़ से निरस्त हो जाता है। कभी-कभी यह एक ऐसा वर्ग होता है जो एक समग्र तत्व का वर्णन करता है जिसकी जड़ पृष्ठ का एक और तत्व है, और पृष्ठ ही नहीं। इसका एक उदाहरण SelectElement है , जो कंस्ट्रक्टर में मूल IWebElement के संदर्भ को स्वीकार करता है।

चलिए WebDriverWait को इनिशियलाइज़ करने के मुद्दे पर वापस आते हैं। इस क्रिया के लिए ड्राइवर की एक आवृत्ति की आवश्यकता होती है। यानी हम हमेशा, एक तरह से या किसी अन्य, क्लाइंट कोड के बाहर से IWebDriver का एक उदाहरण फेंकने की जरूरत है, भले ही यह कुछ मिश्रित तत्व (SelectElement के बारे में एक उदाहरण) का एक वर्ग है, जो पहले से ही एक "माता-पिता" को स्वीकार करता है। मेरे दृष्टिकोण से, यह अनावश्यक है।

बेशक, हम सादृश्य द्वारा एक वर्ग की घोषणा कर सकते हैं

SearchContextWait : DefaultWait<ISearchContext> 

लेकिन चलो जल्दी मत करो। हमें उसकी जरूरत नहीं है।

आइए देखें कि ड्राइवर की स्थिति को किस तरह से उपयोग किया जाता है। आमतौर पर यह कुछ इस तरह दिखता है:

 var wait = new WebDriverWait(Driver, TimeSpan.FromSeconds(10)); wait.Until( d => d.FindElements(By.XPath("locator")).Count > 0 ); 

सवाल यह उठता है कि क्लाइंट कोड से हमेशा उपलब्ध होने पर ड्राइवर का "स्थानीय" संस्करण क्यों आवश्यक है? इसके अलावा, यह वही उदाहरण है जो पहले कंस्ट्रक्टर के माध्यम से पारित किया गया था। यानी कोड कुछ इस तरह दिख सकता है:

 var wait = new WebDriverWait(Driver, TimeSpan.FromSeconds(10)); wait.Until( d => Driver.FindElements(By.XPath("locator")).Count > 0 ); 

यहां तक ​​कि साइमन स्टीवर्ट अपने भाषण में इस दृष्टिकोण का उपयोग करते हैं ।



वह "डी -> डी" नहीं लिखता है, लेकिन "डी -> ड्राइवर" लिखता है, यानी। ड्राइवर उदाहरण को विधि में पारित कर दिया गया है। लेकिन इसे प्रसारित करना आवश्यक है, क्योंकि विधि हस्ताक्षर की आवश्यकता है!

विधि की स्थिति के अंदर ड्राइवर को क्यों पास करें? इस विधि के अंदर खोज को अलग करना संभव है, जैसा कि ExpectedConditions में लागू किया गया है? TextToBePresentInElement विधि के कार्यान्वयन पर एक नज़र डालें। या दृश्यता । या TextToBePresentInElementValue । हस्तांतरित चालक का उपयोग भी उनमें नहीं किया जाता है!

तो, पहला विचार यह है कि हमें प्रतिनिधि पद्धति के साथ टिल विधि की आवश्यकता नहीं है जिसे ड्राइवर स्वीकार करता है।

आइए अब पता लगाते हैं कि क्या जब तक विधि को वापसी मूल्य की आवश्यकता है? यदि बूल TResult के रूप में कार्य करता है, तो नहीं, यह आवश्यक नहीं है। वास्तव में, सफलता के मामले में, आप सच हो जाएंगे, और विफलता के मामले में, आपको टाइमआउट अपवाद मिलेगा। ऐसे व्यवहार की सूचना सामग्री क्या है?

लेकिन क्या होगा अगर वस्तु TResult है? निम्नलिखित निर्माण मान लें:

 var wait = new WebDriverWait(Driver, TimeSpan.FromSeconds(10)); wait.IgnoreExceptionTypes(typeof(NoSuchElementException)); var element = wait.Until(d => d.FindElement(By.XPath("locator"))); 

यानी हम न केवल तत्व की उपस्थिति की प्रतीक्षा करते हैं, बल्कि इसका उपयोग भी करते हैं (यदि हमने इंतजार किया है), जिससे डोम को एक अनावश्यक कॉल हटा दिया जाता है। सब ठीक है।

आइए कोड के इन तीन लाइनों पर एक करीब से नज़र डालें। टिल विधि के कार्यान्वयन के अंदर, यह एक प्रकार की समानता (सशर्त कोड) को उबालता है

 try { FindElement } catch (NoSuchElementException) {} 

यानी जब तक तत्व DOM में प्रकट नहीं होता तब तक हर बार एक अपवाद को फेंक दिया जाएगा। चूंकि अपवाद की पीढ़ी एक महंगी घटना है, इसलिए मैं इससे बचना पसंद करूंगा, खासकर उन जगहों पर जहां यह मुश्किल नहीं है। हम निम्नानुसार कोड को फिर से लिख सकते हैं:

 var wait = new WebDriverWait(Driver, TimeSpan.FromSeconds(10)); var elements = wait.Until(d => d.FindElements(By.XPath("locator"))); 

यानी हम फाइंडलाइज़ का उपयोग करते हैं, जो अपवाद नहीं है। रुको, क्या यह डिज़ाइन तत्वों की उपस्थिति की प्रतीक्षा करेगा? नहीं! क्योंकि, यदि आप स्रोत कोड को देखते हैं , तो एक अनंत लूप तुरंत पूरा हो जाता है, जैसे ही स्थिति गैर-अशक्त हो जाती है। और विफलता के मामले में FindElements एक खाली संग्रह लौटाता है, लेकिन किसी भी तरह से अशक्त नहीं। यानी वस्तुओं की एक सूची के लिए, जब तक कोई मतलब नहीं है का उपयोग कर।

ठीक है, सूची स्पष्ट है। लेकिन फिर भी, पाया तत्व कैसे लौटाएं और अपवाद न फेंकें? कोड इस तरह दिख सकता है:

 var wait = new WebDriverWait(Driver, TimeSpan.FromSeconds(10)); var element = wait.Until(d => d.FindElements(By.XPath("locator")).FirstOrDefault()); 

इस मामले में, लूप के प्रत्येक पुनरावृत्ति पर, हम न केवल IWebElement सूची (जो खाली हो सकती है) प्राप्त करेंगे, बल्कि इसमें से पहला तत्व निकालने का भी प्रयास करेंगे। यदि तत्व अभी भी पृष्ठ पर प्रदर्शित नहीं होते हैं, तो हम अशक्त (ऑब्जेक्ट के लिए डिफ़ॉल्ट मान) प्राप्त करेंगे और लूप के अगले पुनरावृत्ति पर आगे बढ़ेंगे। यदि तत्व पाया जाता है, तो हम विधि से बाहर निकल जाएंगे और तत्व चर को रिटर्न वैल्यू के साथ आरंभ किया जाएगा।

और फिर भी, दूसरा विचार यह है कि अधिकतर मामलों में टिल विधि का वापसी मूल्य उपयोग नहीं किया जाता है।

पारित मूल्य अनावश्यक है, वापसी मूल्य का उपयोग नहीं किया जाता है। तक की उपयोगिता क्या है? केवल स्थिति पद्धति को कॉल करने के चक्र और आवृत्ति में? इस दृष्टिकोण को पहले से ही SpinWait.SpinUntil पद्धति में C # में लागू किया गया है। इसका एकमात्र अंतर यह है कि यह टाइमआउट अपवाद नहीं फेंकता है। यह इस प्रकार तय किया जा सकता है:

 public void Wait(Func<bool> condition, TimeSpan timeout) { var waited = SpinWait.SpinUntil(condition, timeout); if (!waited) { throw new TimeoutException(); } } 

यानी अधिकांश मामलों में कोड की ये कुछ पंक्तियाँ पूरे WebDriverWait वर्ग के तर्क को बदल देती हैं। क्या परिणाम के लायक प्रयास हैं?

अद्यतन

लेख के लिए टिप्पणियों में, केएसए उपयोगकर्ता ने स्पिनयूटिल के बीच और स्थिति की आवृत्ति के संदर्भ में अंतर के बारे में एक समझदार टिप्पणी की। WebDriverWait के लिए, यह मान समायोज्य है और 500 मिलीसेकंड के लिए डिफ़ॉल्ट है। यानी जब तक विधि लूप पुनरावृत्तियों के बीच एक देरी है। जबकि स्पिनअंटिल के लिए तर्क थोड़ा जटिल है और अक्सर प्रतीक्षा 1 मिलीसेकंड से अधिक नहीं होती है।

व्यवहार में, यह ऐसी स्थिति में होता है, जहां 2 सेकंड के भीतर दिखाई देने वाले तत्व की प्रतीक्षा करते समय, Unitl विधि 4 पुनरावृत्तियों को निष्पादित करती है, और SpinUntil विधि लगभग 200 या अधिक लेती है।

आइए SpinUntil को त्यागें और प्रतीक्षा विधि को फिर से लिखें।

 public void Wait(Func<bool> condition, TimeSpan timeout, int evaluatedInterval = 500) { Stopwatch sw = Stopwatch.StartNew(); while (sw.Elapsed < timeout) { if (condition()) { return; } Thread.Sleep(evaluatedInterval); } throw new TimeoutException(); } 

हमने कोड की कुछ पंक्तियाँ जोड़ीं, और साथ ही हम टिल विधि के तर्क के करीब पहुँच गए।