यह सर्वर के पक्ष में होने वाली सामग्री के परीक्षणों को लिखने के लिए काफी स्पष्ट है, लेकिन मैंने सुना है कि यूआई सामान के लिए इकाई परीक्षण लिखना वाकई मुश्किल है और वे नाजुक और अविश्वसनीय हैं। मुझे और अधिक विश्वास होना अच्छा लगेगा कि मेरे द्वारा किए गए परिवर्तन मेरी साइट पर आयात पृष्ठों के प्रमुख हिस्सों को तोड़ नहीं देते हैं।क्या ब्राउज़र के साथ काम करने वाले परीक्षण लिखने के प्रयास के लायक है (जैसे सेलेनियम या कुछ का उपयोग करना)?
कोई विचार या अनुभव?
मैंने उन्हें विकास के हिस्से के रूप में उपयोग किया। उनके बारे में अच्छी बात यह है कि आप उन्हें आईई में भी निष्पादित कर सकते हैं (आपको इसके लिए सेलेनियम सर्वर की आवश्यकता है)। मैंने उन्हें केवल विकास चरण पर इस्तेमाल किया और यूनिट परीक्षणों की तरह उनका इलाज नहीं किया। अगर मैं कुछ यूआई विशिष्ट तर्क करता हूं तो वे बहुत मदद करते हैं।
सबसे महत्वपूर्ण बात यह है कि सभी प्रयुक्त HTML तत्वों को आईडी असाइन करना है। इसके बिना परीक्षण बहुत नाजुक हैं। टिप्पणियों का उपयोग करने में भी मदद मिलती है।
यह आसान है, गैर-तकनीकी व्यक्ति द्वारा किया जा सकता है और निश्चित रूप से प्रयास के लायक है। यूआई परीक्षण डेस्कटॉप एप्लिकेशन के लिए कठिन है, वेब ऐप्स के लिए इतना कठिन नहीं है क्योंकि आप नियंत्रण को स्थानांतरित कर सकते हैं और सेलेनियम अभी भी उन्हें HTML में ढूंढ पाएगा। गरीब डेस्कटॉप डेवलपर्स के लिए ऐसी कोई किस्मत नहीं।
बेशक हमेशा एक संभावना है कि आप इसे उस बिंदु पर अधिक कर दें जहां यह आपको प्रयास की तुलना में बहुत अधिक वापस नहीं देता है लेकिन यह सामान्य इकाई परीक्षण के साथ समान है। आपको पता होना चाहिए कि कब रुकना है।
आप browsershots.org का उपयोग कर सकते हैं ताकि वहां लगभग हर ब्राउज़र में अपने पृष्ठों को देखने के लिए उपयोग किया जा सके।
आवेदन के विभिन्न गतिशीलता को बेहतर बनाने के लिए आप जितने अधिक परीक्षण लिखते हैं उतना बेहतर। जब समय आता है कि आपको ऐप द्वारा उत्पन्न पृष्ठ पर कुछ बदलना होगा - तो आपके परीक्षण आपको बताएंगे कि कुछ तोड़ता है या नहीं।
हाँ वे कमजोर कर रहे हैं और हाँ अपनी एक दर्द पागल चयनकर्ता रास्तों सिर्फ सही ...
यूआई परीक्षण काम कर, धीमी गति से कमजोर और दर्दनाक बनाए रखने के लिए किया जा सकता है रखने, लेकिन कुछ कीड़े केवल यूआई परीक्षण में पकड़ा जा सकता है। महत्वपूर्ण सवाल यह नहीं है कि यूआई परीक्षण लिखना उचित है, लेकिन अपने यूआई परीक्षणों को उपयोगी, स्थिर और रखरखाव कैसे रखें।
अन्य परीक्षणों के लिए एक विकल्प के रूप में यूआई परीक्षणों का उपयोग करना एक आम गलती है। सैद्धांतिक रूप से, आप यूआई परीक्षणों के माध्यम से बहुत सारी कार्यक्षमता का परीक्षण कर सकते हैं, लेकिन उस दृष्टिकोण के साथ कई समस्याएं हैं। स्टार्टर्स के लिए, यूआई (विशेष रूप से असाधारण स्थितियों) में सीधे परीक्षण करने के लिए कुछ कार्यक्षमता बहुत कठिन हो सकती है। दूसरा, यदि कोई परीक्षण विफल रहता है, तो यह देखना मुश्किल होता है कि समस्या का स्रोत क्या है। अंत में, यूआई परीक्षणों में आपके द्वारा परीक्षण किए जाने वाले अधिक कोड पथ, धीमे यूआई परीक्षण प्राप्त होते हैं। यदि आप केवल धीमी परीक्षणों पर भरोसा करते हैं, तो आपकी उत्पादकता और भी खराब हो जाती है, जो टूटने वाले परीक्षणों को केवल "अस्थायी" करने के लिए प्रलोभन को बढ़ाती है।
मेरी सलाह है कि यूनिट परीक्षणों और एकीकरण परीक्षणों में जितना संभव हो सके परीक्षण करें, अपने यूआई और अपने व्यावसायिक तर्क के बीच एक अच्छा अलगाव बनाएं, और अपने यूआई परीक्षणों का उपयोग उन बग को पकड़ने/रोकने के लिए करें जिन्हें अन्य प्रकारों में परीक्षण नहीं किया जा सकता परीक्षण।
यदि आपके पास कई परीक्षण हैं, तो एकाधिक स्वीट बनाने पर विचार करें। मैं यूआई परीक्षणों के लिए एक सुइट बनाता हूं, एकीकरण परीक्षण के लिए एक और यूनिट परीक्षणों के लिए एक। यूनिट परीक्षण बहुत तेज़ होते हैं, इसलिए मैं उन्हें चलाता हूं क्योंकि मैं अपना कोड विकसित करता हूं (अक्सर टीडीडी के माध्यम से)। ये वे परीक्षण हैं जो मुझे उत्पादक बनने में मदद करते हैं।
एकीकरण परीक्षण मैं अक्सर कम चलाता हूं (शायद मैंने कुछ बदलावों को लागू करने के बाद)। जब मैं एक परिवर्तन सबमिट करने के लिए तैयार हो रहा हूं (या जब मैं अधिक यूआई परीक्षण लिखता हूं, तो स्पष्ट रूप से) यूआई परीक्षण चलाता हूं।
सलाह का एक अंतिम सादा: Domain Specific Language के साथ अपने यूआई परीक्षण लिखने पर विचार करें। इससे परीक्षणों को समझना आसान हो जाता है (क्योंकि वे उपयोगकर्ता चरणों के सेट के रूप में पढ़ते हैं, न कि निम्न स्तर के ब्राउज़र क्रियाओं के समूह के रूप में)। यह कोड को बनाए रखने के लिए आसान बना सकता है। उदाहरण के लिए, उपयोगकर्ता को लॉग इन करने के लिए चरण-दर-चरण ब्राउज़र क्रियाओं के माध्यम से प्रत्येक परीक्षण करने के बजाय, आप देख सकते हैं:
LoginPage loginPage = new LoginPage(selenium);
HomePage homePage = loginPage
.enterUserName(TestUsers.Alice.USER_NAME)
.enterPassword(TestUsers.Alice.PASSWORD)
.submit();
assertThat(homePage.getBreadcrumbs(), equalTo("Home"));