अनुबंध बनाम यूनिट टेस्ट

अस्वीकरण: इस नोट का तात्पर्य है कि पाठक को इकाई परीक्षणों के बारे में बुनियादी ज्ञान है, जिसके बारे में इन पंक्तियों के लेखक को कोई संदेह नहीं है, साथ ही अनुबंध के डिजाइन के बारे में बुनियादी ज्ञान है, जिसे यहां से शुरू किया जा सकता है ।

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

तो, चलो ठीक उसी जगह पर नज़र डालते हैं, जहां अनुबंधों और इकाई परीक्षणों का अंतर-बिंदु स्थित है, और इस सवाल का जवाब देने की कोशिश करते हैं: क्या इकाई परीक्षण की उपस्थिति में पद निरर्थक हैं?

ठेके

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

समस्या यह है कि कोड स्वयं सही या गलत नहीं है, शुद्धता की अवधारणा केवल संयोजन में लागू होती है: कोड एक विनिर्देश है। (आप लेख में इसके बारे में अधिक पढ़ सकते हैं: अनुबंध द्वारा डिजाइन। सॉफ्टवेयर शुद्धता ।)

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

हम बाद के तरीके पर विचार करेंगे, लेकिन अभी के लिए, चलिए एक को आगे बढ़ाते हैं: अनुबंधों का उपयोग करते हुए।


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

कक्षा बी पद्धति के पूर्वापेक्षाएँ ग्राहक अनुबंध की बात करती हैं: वर्ग बी के ग्राहकों को अपने कर्तव्यों को लेने के लिए कक्षा बी ग्राहकों को क्या करना चाहिए । कक्षा बी के तरीकों के बाद के वर्ग अपने ग्राहकों से पहले एक वर्ग बी अनुबंध की बात करते हैं: जो वर्ग बी की पूर्ति की गारंटी देता है यदि उसके ग्राहकों ने अनुबंध के अपने हिस्से को पूरा किया है ।

एक अनुबंध का एक उदाहरण IList इंटरफ़ेस की ऐड विधि का अनुबंध है: यदि IList इंटरफ़ेस का क्लाइंट एक गैर-शून्य ऑब्जेक्ट (पूर्व शर्त) से गुजरता है, तो इसे इस संग्रह में जोड़ा जाएगा और तत्वों की संख्या (गणना) 1 (पोस्टकंडिशन) से बढ़ जाएगी।

इकाई परीक्षण

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

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

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

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

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

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

एक व्यावहारिक उदाहरण। इंटरफेस में अनुबंध

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

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

//    [ContractClass(typeof(IListContract<>))] public interface IList<T> { /// <summary> /// Adds an item to the ICollection<T>. /// </summary> void Add(T item); int Count { get; } //     } 

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

 [ContractClassFor(typeof(IList<>))] internal abstract class IListContract<T> : IList<T> { void IList<T>.Add(T item) { Contract.Ensures(this.Count == (Contract.OldValue<int>(this.Count) + 1), "Count == Contract.OldValue(Count) + 1"); } } 

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

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

अनुबंध अतिरिक्त जानकारी प्रदान करते हैं जो इंटरफ़ेस क्लाइंट उपयोग कर सकता है, और, कोई कम महत्वपूर्ण नहीं, एक वर्ग जो इस इंटरफ़ेस को लागू करता है।

निष्कर्ष

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

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