प्रोग्राम इवोल्यूशन और टूटे टेस्ट

Question

यूनिट परीक्षणों को बनाए रखना मुश्किल है। मुझे यकीन है कि हम सभी ने एक ऐसा समय अनुभव किया है जब परीक्षण के तहत सिस्टम में एक छोटे से बदलाव के कारण दर्जनों यूनिट परीक्षण विफल हो गए। कभी-कभी ये विफलताओं एसयूटी में बग प्रकट करती हैं, लेकिन अक्सर परीक्षण पुराने होते हैं और अब एसयूटी के सही व्यवहार को प्रतिबिंबित नहीं करते हैं। इन मामलों में, टूटे हुए परीक्षणों को ठीक करना आवश्यक है।

क्या आपको इस स्थिति का सामना करना पड़ा है? क्या यह अक्सर होता है? आपने किस बदलाव को पेश किया और विफलताओं ने कैसे प्रकट किया? क्या आपने टूटा परीक्षण ठीक किया है या बस उन्हें हटा दिया है? यदि पूर्व, कैसे? अगर उत्तरार्द्ध, क्यों? असफलताओं का डर परीक्षण लिखने की आपकी इच्छा को कैसे प्रभावित करता है?

मैं भी टूटे हुए परीक्षणों के विशिष्ट उदाहरण ढूंढना चाहूंगा। क्या आप किसी भी ओपन-सोर्स अनुप्रयोगों के बारे में जानते हैं जो उन तरीकों से विकसित हुए हैं जिनसे परीक्षण विफल हो गए हैं?

Answer 1

इकाई परीक्षण बनाए रखना मुश्किल है।

पर्याप्त सच है। उत्पादन कोड और परीक्षण कोड का सह-विकास एक साथ कठिन है। दोनों प्रकार के कोड समानताएं साझा करते हैं (जैसे नामकरण सम्मेलन), लेकिन वे अभी भी प्रकृति में भिन्न हैं। उदाहरण के लिए यदि आवश्यक हो तो परीक्षण कोड में डीआरवाई का उल्लंघन किया जा सकता है; कोड डुप्लिकेशन वास्तव में आसानी से पाया जाएगा क्योंकि परीक्षण दोनों जगहों पर टूट जाएगा। परीक्षण और उत्पादन कोड परिणामों के बीच तनाव कभी-कभी विशिष्ट डिजाइन व्यापार-बंद (उदा। निर्भरता इंजेक्शन) में परीक्षण क्षमता को कम करने के लिए होता है। फिर, ये तनाव अपेक्षाकृत नए हैं, और उत्पादन कोड पर डिजाइन और रखरखाव के प्रयास के बीच संबंध अच्छी तरह से समझ में नहीं आता है।आलेख "On the interplay between software testing and evolution" बहुत अच्छा है (मैं इसे पीडीएफ में नहीं ढूंढ पाया, लेकिन लंबे समय तक Google नहीं था)।

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

दोष स्थानीयकरण - ठीक दोष इंगित करने के लिए टेस्ट स्वीट की क्षमता - यह भी केवल आंशिक रूप से समझा जाता है। टेस्ट सूट डिजाइन करने के लिए सबसे अच्छी रणनीतियां क्या हैं जिसके परिणामस्वरूप उच्च दोष स्थानीयकरण स्पष्ट नहीं है। अधिकांश परीक्षणों में उनके बीच कुछ ओवरलैप होता है, जिससे कम दोष स्थानीयकरण होता है। परीक्षण का आदेश ताकि वे एक-दूसरे पर निर्भर हों, इस पहलू को बेहतर बनाते हैं, लेकिन साथ ही अलग परीक्षण होने के सिद्धांत के खिलाफ भी जाते हैं। हम इस तरह के तनावों की बढ़ती जागरूकता देखते हैं, लेकिन इन मुद्दों को हल करने के लिए कोई निश्चित समाधान नहीं है। यहां exploiting dependencies between tests के बारे में एक लेख है।

की समस्या पुरानी या अप्रासंगिक परीक्षण (जो अंत में कुछ भी कवर नहीं करते हैं) भी जागरूकता बढ़ रही है। टेस्ट कवरेज पर्याप्त नहीं है और उच्च गुणवत्ता वाले परीक्षण सूट को अनुभव की आवश्यकता है, या कम से कम, कुछ शिक्षा। इस आलेख को the 100% coverage myth के बारे में देखें।

असफलताओं का डर को परीक्षण लिखने की आपकी इच्छा को कैसे प्रभावित करता है?

आप (1) प्रारंभिक टेस्ट स्वीट (2) रखरखाव और (3) टेस्ट स्वीट की प्रभावशीलता में प्रयास में निवेश समय के बीच एक संतुलन लगाना होगा। मैं अधिकतर लिखता हूं जिसे मैं "इन्फ्लिक्शन पॉइंट टेस्ट" कहता हूं और इस विषय पर my view कहता हूं।

Answer 2

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

Answer 3

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

Answer 4

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

Answer 5

असफलताओं का डर को परीक्षण लिखने की आपकी इच्छा को कैसे प्रभावित करता है?

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

Answer 6

मुझे यकीन है कि हम सब एक समय था जब परीक्षण के अंतर्गत एक से दिखते छोटा सा परिवर्तन व्यवस्था करने के लिए दर्जनों इकाई परीक्षण के विफल वजह से अनुभव किया है हूँ।

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

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

Answer 7

आपके द्वारा वर्णित समस्या यह है कि परियोजना की शुरुआत में सबसे अच्छा संबोधित किया गया है। जिस क्षण से आप अपने यूनिट-टेस्ट (अधिमानतः टीडीडी-शैली) लिखना शुरू करते हैं, आपको लगातार प्रकट होने और विकसित होने के तरीके से अवगत होना चाहिए।
यहां कोई जादू चाल नहीं है, आपको कड़ी मेहनत करनी होगी और ध्यान दें कि जब आप एक उलझन वाली गड़बड़ी कर रहे हैं जो वास्तव में परीक्षणों को बनाए रखना कठिन बना देगा। आम तौर पर, यदि परीक्षण इतने उलझन में हैं, तो इसका तात्पर्य है कि कुछ उत्पादन कोड कुछ रिफैक्टरिंग का भी उपयोग कर सकते हैं।

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

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

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

Answer 8

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

कई मामलों में, कोड को गुणवत्ता में सुधार करने के लिए आवश्यक परिवर्तनों को कोड की गुणवत्ता में सुधार करने का दुष्प्रभाव होगा - उदाहरण के लिए, इंटरफ़ेस के बीच इंटरफ़ेस को परिभाषित करने में सहायता करके।

Answer 9

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

Answer 10

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

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

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

Answer 11

यहां एक विचार प्रयोग है। यह केवल एक रेंट

इसके बजाय अपने यूनिट परीक्षणों को बनाए रखने का प्रयास न करें।

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

(: "बिग बैंग एकीकरण": वैसे इस परीक्षण आहार एक नाम है जब आप में इलेक्ट्रॉनिक्स यह कोशिश यह सचमुच एक धमाके के रूप में सभी उपकरणों में आग लग जाती।)

के बारे में बताएं कितना काम यह किया गया था बनाए रखें, और यह समय बचा नहीं है।

उनके चेहरे पर नज़र डालें। सर्वोत्तम प्रभाव के लिए, किसी ऐसे व्यक्ति को चुनें जो आपके इलाके में लाइसेंस प्राप्त पीई (व्यावसायिक अभियंता) है।

इसे दोहराएं, लेकिन अपने आईएसओ 9000 ऑडिटर से व्यक्ति को प्रतिस्थापित करें, जहां आप उन्हें संशोधित विकास प्रक्रिया दिखाते हैं जिसमें एकीकरण तक कोई परीक्षण नहीं होता है।

फिर से दोहराएं, एक सीएमएमआई निर्धारक को प्रतिस्थापित करें। यह आखिरी एक मजाकिया होगा। सीएमएमआई एससीएएमपीआई निर्धारकों को "यह बहुत अधिक प्रयास था"

अब, आप शायद सोच रहे हैं कि आप कहीं भी आईएसओ 9000 या सीएमएमआई के साथ काम नहीं करते हैं, और अन्य डिस्प्ले इंजीनियरों के साथ काम नहीं करते हैं।

किस बिंदु पर, समस्या यह है कि एक औसत सॉफ्टवेयर की दुकान शायद यूनिट परीक्षण नहीं करती है।

तो औसत-नेस स्वीकार करें, और स्थापित उद्योग को सबसे खराब प्रथाओं का उपयोग करें। फिर < पर ऑफशोरिंग > पर कहीं भी सस्ता देश डालें, या तो कोई गुणवत्ता प्रभाव नहीं हो सकता है (कोई प्रक्रिया खराब नहीं है)। तो, वास्तव में, आपके मालिक को अब काम को दूर करना चाहिए और पैसा बचाना चाहिए। कहीं इस तर्क के साथ कुछ गड़बड़ है।

Answer 12

टूटे हुए परीक्षण अभ्यास में एक बड़ी समस्या है। मैंने कई समूहों को आक्रामक परीक्षण पर छोड़ दिया है क्योंकि टूटे हुए परीक्षणों को बनाए रखने की लागत भारी है। यहां एक संबंधित बात है जो ब्याज की हो सकती है। https://sites.google.com/a/allegheny.edu/regression-2012/acknowledging-the-elephant-in-the-room-brittle-test-cases