द एजिल वे: एकीकरण परीक्षण बनाम कार्यात्मक परीक्षण या दोनों?

Question

मैं एक ऐसे कार्यालय में काम करता हूं जो थोड़ी देर के लिए एग्इल कर रहा है। हम परियोजना प्रबंधन के लिए स्क्रम का उपयोग करते हैं और एक्सपी के इंजीनियरिंग प्रथाओं में मिश्रण करते हैं। यह अच्छी तरह से काम करता है और हम लगातार पाठ सीख रहे हैं और हमारी प्रक्रिया को परिष्कृत कर रहे हैं।

मैं परीक्षण के लिए हमारी सामान्य व्यवहार के बारे में आपको बता और पर प्रतिक्रिया प्राप्त करना चाहते हैं कि यह कैसे सुधार किया जा सकता:

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

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

कार्यात्मक परीक्षण हम आमतौर पर इसे एक संरचित, लेकिन मैन्युअल फैशन में करते हैं। हमने सेलेनियम और विंडमिल के साथ खेला है, जो कि शांत हैं, लेकिन हमारे लिए कम से कम अभी तक काफी नहीं है।

मैं सुनना चाहता हूं कि कोई और चीजें कैसे कर रहा है। क्या आपको लगता है कि अगर एकीकरण टेस्ट या कार्यात्मक परीक्षण किया जा रहा है तो अन्य को नजरअंदाज किया जा सकता है?

Answer 1

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

इसके अलावा, इकाई परीक्षण वास्तव में आपके कोड का परीक्षण करने के बारे में नहीं है, खासकर यदि आप टीडीडी का अभ्यास कर रहे हैं। TDD helps you design your code better की प्रक्रिया, आपको इसके अंत में परीक्षणों के सूट का अतिरिक्त बोनस मिलता है।

आपने यह उल्लेख नहीं किया है कि आपके पास निरंतर एकीकरण सर्वर चल रहा है या नहीं। मैं दृढ़ता से एक सेट अप करने की अनुशंसा करता हूं (Hudson सेट करना आसान है)। फिर आप कोड के प्रत्येक चेक के खिलाफ अपना एकीकरण और कार्यात्मक परीक्षण चला सकते हैं।

Answer 2

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

Answer 3

मैं कहूंगा (और यह सिर्फ राय का विषय है) कि आपके कार्यात्मक परीक्षण आपके सच परीक्षण हैं। यानी वे परीक्षण जो वास्तव में आपके आवेदन के वास्तविक जीवन उपयोग को अनुकरण करते हैं। इस कारण से, इससे कोई फर्क नहीं पड़ता, इससे कोई फर्क नहीं पड़ता।

ऐसा लगता है कि आपके पास एक सभ्य प्रणाली चल रही है। अगर आपके पास हारने के लिए कुछ भी नहीं है तो इसे सब कुछ रखें।

Answer 4

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

और यदि कोई बग है जिस पर एप्लिकेशन में कोई परिणाम नहीं है, जो वास्तव में परवाह करता है? लेकिन वास्तविक जीवन जटिलताओं के आस-पास के मुद्दे हमेशा होते हैं; क्या आप सुनिश्चित हैं कि आपके कार्यात्मक परीक्षण सही परिदृश्यों को कैप्चर कर रहे हैं? अन्य प्रणालियों के कारण अंतर्निहित जटिलताएं हो सकती हैं जो आवेदन के व्यवहार में सीधे दिखाई नहीं दे रही हैं।

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

Answer 5

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

मैंने इस अभ्यास की प्रासंगिकता के बारे में question से पूछा है और संक्षेप में यह था कि व्यावहारिक रूप से पृथक्करण तेजी से/सरल परीक्षणों के बीच होता है जो हर निर्माण और धीमी/जटिल परीक्षणों में स्वचालित रूप से चलाया जाता है।

Answer 6

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

Answer 7

मेरे वर्तमान ग्राहक पर हम यूनिट-टेस्ट और एकीकरण-परीक्षणों के बीच वास्तव में अलग नहीं होते हैं। व्यापार संस्थाएं अंतर्निहित डेटा-लेयर (होमग्राउन ओआरएम फ्रेमवर्क का उपयोग करके) पर इतनी निर्भर हैं कि असल में हमारे पास बहुत कम या कोई वास्तविक इकाई-परीक्षण नहीं है।

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

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

"फास्ट" परीक्षण यूनिट-टेस्ट की तरह अधिक होते हैं, जहां आप एक वस्तु के राज्य और व्यवहार को उचित रूप से अलग कर सकते हैं कसौटी।

मैं किसी भी परीक्षण पर विचार करता हूं जो कि "तेज़" होने के लिए दूसरे या उससे कम के दसवें हिस्से में चलता है। कुछ और धीमा है और शायद सीआई के हिस्से के रूप में नहीं चलाया जाना चाहिए।

मैं मानता हूं कि आपको विकास के हिस्से के रूप में उपयोग किए जाने वाले परीक्षण के "स्वाद" पर भी लटका नहीं जाना चाहिए (स्वीकृति मानदंड व्यक्त करना क्योंकि परीक्षण पाठ्यक्रम का अपवाद है)। व्यक्तिगत डेवलपर को यह तय करने में अपने फैसले का उपयोग करना चाहिए कि किस प्रकार के परीक्षण उनके कोड के अनुरूप हैं। किसी व्यापार इकाई के लिए यूनिट-टेस्ट पर जोर देने से दोषों को कोई सीआरयूडी-टेस्ट नहीं होगा और ...

Answer 8

मुझे वास्तव में गोजको एडज़िक की "फेस सेविंग टेस्ट" की अवधारणा पसंद है, यह निर्धारित करने के लिए कि आप क्या परीक्षण करते हैं यूआई के माध्यम से: http://gojko.net/2007/09/25/effective-user-interface-testing/

Answer 9

आपको उन सभी को करना चाहिए क्योंकि यूनिट, एकीकरण और कार्यात्मक परीक्षण सभी अलग-अलग उद्देश्यों को पूरा करते हैं।
मेरा है एक महत्वपूर्ण मुद्दा यह है कि जिस तरह से लिखने परीक्षण बहुत महत्वपूर्ण है और TDD enought, BDD (व्यवहार संचालित विकास) एक अच्छा दृष्टिकोण देना नहीं है ...

Answer 10

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