unit testing - .NET 4.0 कोड अनुबंध-वे यूनिट परीक्षण को कैसे प्रभावित करेंगे?




unit-testing .net-4.0 (3)

क्या फायदा है?

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

कोड कॉन्ट्रैक्ट के साथ, आप बस यह घोषित करते हैं कि विधि कभी भी null नहीं होती है। स्थिर विश्लेषक तब शिकायत करेगा यदि यह साबित करना संभव नहीं है। यदि यह शिकायत नहीं करता है, तो आप जानते हैं कि आपका आश्वासन सभी संभावित आदानों के लिए सही है।

कम काम, सही शुद्धता की गारंटी। क्या पसंद नहीं करना?

उदाहरण के लिए यह article उनका परिचय देता है।

क्या फायदा है?

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

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

अद्यतन करें

कोड अनुबंध के साथ खेलने के बाद मैं थोड़ा निराश हूं। उदाहरण के लिए, स्वीकृत उत्तर में कोड के आधार पर:

public double CalculateTotal(Order order)
{
    Contract.Requires(order != null);
    Contract.Ensures(Contract.Result<double>() >= 0);
    return 2.0;
}

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

अनिवार्य रूप से वे सभी बयान लिखने के लिए वैकल्पिक तरीके से उबलते हैं। कोड कॉन्ट्रैक्ट्स के साथ वास्तव में TDD का उपयोग करने का मेरा अनुभव बताता है कि मैं इसके बारे में क्यों और कैसे गया।


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

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

आप बता सकते हैं कि अनुबंध में शून्य वैध मूल्य है।

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


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

अगर मैं इसके बारे में उस दृष्टिकोण से सोचता हूं तो मुझे लगता है कि यह मानक एक से प्रक्रिया को बदल सकता है / कर सकता है

  • बनाने की विधि (सिर्फ हस्ताक्षर)
  • यूनिट टेस्ट बनाएं -> टेस्ट को लागू करें
  • परीक्षण चलाएं: इसे विफल होने दें
  • विधि को लागू करें, इसे काम करने के लिए अंत में हैक करें
  • परीक्षण चलाएँ: इसे पास देखें
  • आपके (संभवतः गन्दा) विधि शरीर को रिफलेक्टर करता है
  • (आप केवल कुछ भी नहीं तोड़ा है देखने के लिए परीक्षण फिर से चलाएँ)

यह वास्तव में कठिन-पूर्ण विशेषताओं वाली इकाई-परीक्षण प्रक्रिया होगी। इस तरह के संदर्भ में मुझे लगता है कि आप 1 और 2 के बीच कोड अनुबंध डाल सकते हैं जैसे

  • बनाने की विधि (सिर्फ हस्ताक्षर)
  • तरीकों इनपुट मापदंडों के लिए कोड अनुबंध डालें
  • यूनिट टेस्ट बनाएं -> टेस्ट को लागू करें
  • ...

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

संपादित करें

एक और संभावना जिस पर मैंने विचार नहीं किया, वह यह होगा कि रिफैक्टिंग भाग में कोड कॉन्ट्रैक्ट्स को जोड़ना होगा। मूल रूप से चीजों को आश्वस्त करने के अतिरिक्त तरीके के रूप में। लेकिन यह किसी भी तरह बेमानी होगा और चूंकि लोग अनावश्यक सामान करना पसंद नहीं करते हैं ...





microsoft-contracts