केवल सार्वजनिक तरीकों से परीक्षण बुरा है

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


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

माइनस 1: यूनिट टेस्ट ओवरकंफिगेशन

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

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

माइनस 2: अधूरा कवरेज

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

private bool HasShifts(DateTime date, int tolerance, bool clockIn, Shift[] shifts, int[] locationIds) { bool isInLimit(DateTime date1, DateTime date2, int limit) => Math.Abs(date2.Subtract(date1).TotalMinutes) <= limit; var shiftsOfLocations = shifts.Where(x => locationIds.Contains(x.LocationId)); return clockIn ? shiftsOfLocations.Any(x => isInLimit(date, x.StartDate, tolerance)) : shiftsOfLocations.Any(x => isInLimit(date, x.EndDate, tolerance)); } 

इस विधि को सभी मामलों को कवर करने के लिए 10 चेक की आवश्यकता होती है, जिनमें से 8 महत्वपूर्ण हैं।


इस तर्क का परीक्षण करने के लिए इकाई परीक्षण लिखते समय, एक डेवलपर को कम से कम 8 बड़ी इकाई परीक्षण लिखने होंगे। मुझे ऐसे मामले सामने आए जब यूनिट टेस्ट कॉन्फ़िगरेशन में कोड की 50+ लाइनें, एक डायरेक्ट कॉल की 4 लाइनें थीं। यानी केवल 10% कोड ही पेलोड ले जाता है। इस मामले में, कम यूनिट परीक्षण लिखकर काम की मात्रा को कम करने के लिए प्रलोभन महान है। नतीजतन, 8 में से, उदाहरण के लिए, केवल दो यूनिट परीक्षण रहते हैं, प्रत्येक घड़ी के लिए। यह स्थिति इस तथ्य की ओर ले जाती है कि या तो, फिर से, थकाऊ और लंबे समय तक सभी आवश्यक परीक्षण लिखने के लिए, कॉन्फ़िगरेशन (Ctrl + C, V काम करता है, जहां इसके बिना), या विधि केवल आंशिक रूप से कवर रहती है। प्रत्येक विकल्प के अपने अप्रिय परिणाम होते हैं।

संभव समाधान

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

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

परिणाम

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