यूनिट परीक्षण डीबग.एएसएसर्ट() अनावश्यक बनाता है?

Question

यह थोड़ी देर के लिए मैंने मैकननेल के "Code Complete" तैयार किया है। अब मैं इसे फिर से पढ़ता हूं & थॉमस 'The Pragmatic Programmer ": दावे का प्रयोग करें! नोट: यूनिट परीक्षण दावे नहीं, मेरा मतलब है Debug.Assert()।

SO प्रश्नों के बाद When should I use Debug.Assert()? और When to use assertion over exceptions in domain classes दावा विकास के लिए उपयोगी हैं, क्योंकि "असंभव" परिस्थितियां काफी तेजी से पाई जा सकती हैं। और ऐसा लगता है कि वे आमतौर पर उपयोग किया जाता है। जहां तक ​​मैं अनुमानों को समझता हूं, सी # में उन्हें अक्सर "असंभव" मानों के लिए इनपुट चर की जांच के लिए उपयोग किया जाता है।

यूनिट परीक्षणों को संक्षिप्त और यथासंभव अलग रखने के लिए, मैं कक्षाओं और विधियों को null एस और "असंभव" डमी इनपुट (खाली स्ट्रिंग की तरह) के साथ फ़ीड करता हूं।

ऐसे परीक्षण स्पष्ट रूप से दस्तावेज कर रहे हैं, कि वे कुछ विशिष्ट इनपुट पर भरोसा नहीं करते हैं। नोट: मैं अभ्यास कर रहा हूं कि मेज़ारोस '' xUnit टेस्ट पैटर्न "Minimal Fixture के रूप में वर्णन कर रहा है।

और यही बात है: अगर मुझे इन इनपुटों की रक्षा करने का दावा होगा, तो वे मेरे यूनिट परीक्षणों को उड़ा देंगे।

मुझे आर्टेटिव प्रोग्रामिंग का विचार पसंद है, लेकिन दूसरी तरफ मुझे इसे मजबूर करने की आवश्यकता नहीं है। वर्तमान में मैं Debug.Assert() के लिए किसी भी उपयोग के बारे में नहीं सोच सकता। शायद मुझे कुछ याद आती है? क्या आपके पास कोई सुझाव है, जहां वे वास्तव में उपयोगी हो सकते हैं? हो सकता है कि मैं सिर्फ दावे की उपयोगिता को अधिक महत्व देता हूं? या शायद परीक्षण के मेरे तरीके की समीक्षा की जरूरत है?

संपादित करें: Best practice for debug Asserts during Unit testing बहुत समान है, लेकिन यह मुझे परेशान करने वाले प्रश्न का उत्तर नहीं देता है: यदि मुझे परीक्षण किया गया है तो मुझे Debug.Assert() पर ध्यान देना चाहिए? यदि हां, तो किस स्थिति में वे वास्तव में उपयोगी हैं? मेरे वर्तमान दृष्टिकोण में ऐसे यूनिट टेस्ट Debug.Assert() अनावश्यक बना देंगे।

एक और बिंदु: यदि आप वास्तव में सोचते हैं, यह एक डुप्लिकेट प्रश्न है, तो बस कुछ टिप्पणी पोस्ट करें।

Answer 1

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

संक्षेप में, वे केवल यूनिट परीक्षणों से एक अलग उद्देश्य प्रदान करते हैं। वे गलतियों को पकड़ने के लिए वहां हैं कि यूनिट परीक्षण लिखते समय उनकी प्रकृति द्वारा नहीं किया जा रहा है।

मैं उन्हें रखने की सलाह दूंगा, क्योंकि वे प्रोग्रामर गलतियों से सुरक्षा का एक और स्तर प्रदान करते हैं।

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

Answer 2

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

Answer 3

मैं विभिन्न उद्देश्यों के लिए, इकाई परीक्षण और दावे दोनों का उपयोग कर रहा हूं।

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

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

Answer 4

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

Answer 5

मैं आम तौर पर तर्क जांच की तरह चीजों की बजाय आंतरिक स्थिति पर सैनिटी चेक के लिए उपयोग किए जाने वाले आवेषण देखता हूं।

आईएमओ एक ठोस एपीआई के इनपुट को बिल्ड प्रकार के बावजूद मौजूद चेक द्वारा संरक्षित किया जाना चाहिए। उदाहरण के लिए, यदि कोई सार्वजनिक विधि उस तर्क की अपेक्षा करती है जो 5 और 500 के बीच की संख्या है, तो उसे ArgumentOutOfRangeException से संरक्षित किया जाना चाहिए। जहां तक ​​मेरा संबंध है, अपवादों का उपयोग करते हुए अक्सर तेजी से विफल रहता है और विफल रहता है, खासकर जब किसी तर्क को कहीं और धक्का दिया जाता है और बाद में इसका उपयोग किया जाता है।

हालांकि, उन जगहों पर जहां आंतरिक, क्षणिक स्थिति सैनिटी-चेक की जा रही है (उदाहरण के लिए कि कुछ मध्यवर्ती राज्य लूप के दौरान उचित सीमाओं के भीतर है), ऐसा लगता है कि डीबग.एस्र्ट घर पर अधिक है। वैध तर्क होने के बावजूद आपका एल्गोरिदम गलत हो गया है, तो आप और क्या करना चाहते हैं? एक EpicFailException फेंको? :) मुझे लगता है कि यह वह जगह है जहां Debug.Assert अभी भी उपयोगी है।

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

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