क्या परीक्षण उद्देश्यों के लिए कोड को सख्ती से संशोधित करना एक बुरा अभ्यास है

Question

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

मेरी राय है कि यह ठीक है, अच्छी वस्तु उन्मुख और सॉफ्टवेयर इंजीनियरिंग प्रथाओं को बनाए रखने की सीमा के भीतर ("सब कुछ सार्वजनिक नहीं कर रहा है", आदि)।

मेरे सहयोगी की राय यह है कि केवल परीक्षण उद्देश्यों के लिए संशोधित कोड (जो काम करता है) गलत है।

बस एक सरल उदाहरण, कोड के इस टुकड़े के बारे में सोचें जो कुछ घटक द्वारा उपयोग किया जाता है (सी # में लिखा है):

public void DoSomethingOnAllTypes()
{
    var types = Assembly.GetExecutingAssembly().GetTypes();

    foreach (var currentType in types)
    {
        // do something with this type (e.g: read it's attributes, process, etc).
    }
}

मैंने सुझाव दिया है कि इस कोड को किसी अन्य विधि से कॉल करने के लिए संशोधित किया जा सकता है जो वास्तविक कार्य करेगा:

public void DoSomething(Assembly asm)
{
    // not relying on Assembly.GetExecutingAssembly() anymore...
}

यह विधि काम करने के लिए एक असेंबली ऑब्जेक्ट में ले जाती है, जिससे परीक्षण करने के लिए अपनी स्वयं की असेंबली को पास करना संभव हो जाता है। मेरे सहयोगी को नहीं लगा कि यह एक अच्छा अभ्यास है।

एक अच्छा और सामान्य अभ्यास क्या माना जाता है?

Comments

आपकी संशोधित पद्धति Typeको एक पैरामीटर के रूप में लेना चाहिए , न कि एक Assembly।

— रॉबर्ट हार्वे

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

— liortal

आपकी कार में "परीक्षण" के लिए एक ओडीबीआई पोर्ट है - अगर चीजें सही होती तो इसकी आवश्यकता नहीं होती। मेरा अनुमान है कि आप कार उसके सॉफ्टवेयर से अधिक विश्वसनीय हैं।

— मटनज़

उसे क्या आश्वासन है कि कोड "काम करता है"?

— क्रेग

अवश्य - ऐसा करें। समय के साथ परीक्षण कोड स्थिर है। लेकिन आपके पास नए शुरू किए गए बगों को समझाने के लिए बहुत आसान समय होगा यदि वे परीक्षण क्षमता के लिए कुछ सुधार के बजाय कुछ सुधार के साथ आए

— पेट्टर नॉर्डलैंडर

Answer 1

इसे अधिक परीक्षण योग्य बनाने के लिए कोड को संशोधित करने से परीक्षण क्षमता से परे लाभ होते हैं। सामान्य तौर पर, कोड जो अधिक परीक्षण योग्य है

• बनाए रखना आसान है,
• के बारे में तर्क करना आसान है,
• अधिक शिथिल युग्मित है, और
• एक बेहतर समग्र डिजाइन है, वास्तुशिल्प रूप से।

Comments

मैंने अपने उत्तर में इन बातों का उल्लेख नहीं किया, लेकिन मैं पूरी तरह सहमत हूँ। अपने कोड को अधिक परीक्षण योग्य बनाने के लिए कई सुखद दुष्प्रभाव होते हैं।

— जेसन स्वेत

+1: मैं आमतौर पर सहमत हूं। निश्चित रूप से स्पष्ट मामले हैं जहां कोड को परीक्षण योग्य बनाने से इन अन्य लाभकारी लक्ष्यों को नुकसान पहुंचता है, और उन मामलों में परीक्षणनीयता सबसे कम प्राथमिकता पर है। लेकिन सामान्य तौर पर, यदि आपका कोड परीक्षण करने के लिए पर्याप्त रूप से लचीला / एक्स्टेंसिबल नहीं है, तो यह लचीला / एक्स्टेंसिबल का उपयोग करने के लिए या शान से उम्र के लिए पर्याप्त नहीं होगा।

— तेलस्टिन

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

— दोस्तों

ठीक ठीक। मुझे याद है कि मैं अपने कोड के लगभग 10k स्रोत लाइनों के लिए यूनिट परीक्षण लिख रहा था। मुझे पता था कि कोड पूरी तरह से काम कर रहा था, लेकिन परीक्षणों ने मुझे कुछ स्थितियों पर पुनर्विचार करने के लिए मजबूर किया। मुझे खुद से पूछना था "यह विधि वास्तव में क्या कर रही है?"। मुझे काम करने वाले कोड में कई कीड़े देखने को मिले, जो एक नए दृष्टिकोण से देखते हैं।

— सुल्तान

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

— AmericanUmlaut

Answer 2

नाटक में विरोधी प्रतीत होते हैं ।

• एक ओर, आप एनकैप्सुलेशन को लागू करना चाहते हैं
• दूसरी ओर, आप सॉफ्टवेयर का परीक्षण करने में सक्षम होना चाहते हैं

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

static void Main(string[] args)

क्या आपका सहकर्मी आपके कोड में इसे एकमात्र एक्सेस पॉइंट बनाने का प्रस्ताव दे रहा है? क्या बाहरी कॉलर्स द्वारा अन्य सभी कोड अप्राप्य होना चाहिए?

मुश्किल से। फिर कुछ तरीकों को सार्वजनिक करने के लिए क्या ठीक है? यह अंत में, एक व्यक्तिपरक डिजाइन निर्णय नहीं है?

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

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

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

यदि आपके पास केवल आपके एपीआई का एक ही कॉलर है, तो आप नहीं जानते कि आपका एपीआई वास्तव में कितना लचीला है। संभावना है, यह काफी अनम्य है। टेस्ट एक दूसरे क्लाइंट के रूप में कार्य करते हैं , जिससे आपको अपने एपीआई के लचीलेपन पर बहुमूल्य प्रतिक्रिया मिलती है ।

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

Comments

+1 जब आप अपने चालको की सुरक्षा ठीक से करते हैं तो आप सार्वजनिक पद्धति को उजागर करना सुरक्षित समझते हैं।

— शमब्युलेटर

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

— शमूएल

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

— रॉबर्ट हार्वे

Answer 3

लगता है कि आप निर्भरता इंजेक्शन के बारे में बात कर रहे हैं । यह वास्तव में आम है, और IMO, परीक्षण क्षमता के लिए बहुत आवश्यक है।

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

Comments

DI प्रमुख सवाल नहीं है (मैं केवल एक उदाहरण देने की कोशिश कर रहा था), मुद्दा यह था कि क्या यह एक और तरीका प्रदान करने के लिए ठीक होगा जो मूल रूप से बनाने के लिए नहीं था, केवल परीक्षण के लिए।

— झूठा

मुझे पता है। मुझे लगा कि मैंने अपने दूसरे पैराग्राफ में "हाँ" के साथ आपका मुख्य बिंदु संबोधित किया है।

— जेसन स्विट

Answer 4

यह चिकन और अंडे की समस्या का एक सा है।

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

मुझे आपके सहयोगी की बात दिखाई देती है। आपके पास कोड है (संभवतः) काम करता है, और यदि आप जाते हैं और इसे रिफैक्ट करते हैं - जो भी कारण से - वहाँ एक जोखिम है कि आप इसे तोड़ देंगे।

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

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

बेशक, चाहे वह अच्छी व्यवसायिक प्रथा ही क्यों न हो, कीड़े की एक पूरी 'कुख्यात इच्छा ' है।

Comments

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

— हंस-पीटर स्टॉर

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

— शमूएल

Answer 5

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

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

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

(नया कोड, निश्चित रूप से, सक्रिय रूप से बनाए रखा जा रहा है, इसलिए इसे परीक्षण योग्य लिखा जाना चाहिए।)

Answer 6

मुझे लगता है कि आपका सहकर्मी गलत है।

दूसरों ने उन कारणों का उल्लेख किया है कि यह पहले से ही क्यों अच्छी बात है, लेकिन जब तक आपको ऐसा करने के लिए आगे दिया जाता है, आपको ठीक होना चाहिए।

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

जरूरी नहीं कि नई सुविधाओं पर काम करने वाले बनाम रिफैक्टिंग का निर्णय लेने के लिए आपकी जगह है, जिससे आपकी कंपनी / ग्राहक को फायदा होगा।

Answer 7

मैंने यह जाँचने के लिए यूनिट कवरेज के भाग के रूप में कोड कवरेज टूल का उपयोग किया है कि क्या कोड के माध्यम से सभी पथों का प्रयोग किया जाता है। अपने दम पर एक बहुत अच्छे कोडर / परीक्षक के रूप में, मैं आमतौर पर कोड पथ के 80-90% को कवर करता हूं।

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

Answer 8

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

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

समस्या, परीक्षण टूलींग की प्रकृति में है, तो।

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

उत्तर देने के लिए: आपका सहकर्मी सही है, लेकिन संभवतः गलत कारणों से। परीक्षण के लिए कोड में बदलाव न करें, अपने परीक्षण उपकरण को बदलें (या इस तरह के बारीक परीक्षण के बजाय अधिक एकीकरण-शैली इकाई परीक्षण करने के लिए आपकी पूरी परीक्षण रणनीति)।

मार्टिन फाउलर ने अपने लेख Mocks Stubs में इस क्षेत्र के आसपास चर्चा नहीं की है

Answer 9

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

Answer 10

आपके उदाहरणों के बीच कुछ गंभीर अंतर हैं। के मामले में DoSomethingOnAllTypes(), एक निहितार्थ है जो do somethingवर्तमान विधानसभा के प्रकारों पर लागू होता है। लेकिन DoSomething(Assembly asm)यह दर्शाता है कि आप किसी भी विधानसभा को पारित कर सकते हैं ।

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

Answer 11

आपके प्रश्न ने बहुत अधिक संदर्भ नहीं दिया, जिसमें आपके सहयोगी ने तर्क दिया था इसलिए अटकलबाजी के लिए जगह है

"बुरा व्यवहार" या नहीं पर निर्भर करता है कि कैसे और जब परिवर्तन किए जाएंगे।

मेरी राय में एक विधि निकालने के लिए आपका उदाहरण DoSomething(types)ठीक है।

लेकिन मैंने कोड देखा है जो इस तरह ठीक नहीं है :

public void DoSomethingOnAllTypes()
{
  var types = (!testmode) 
      ? Assembly.GetExecutingAssembly().GetTypes() 
      : getTypesFromTestgenerator();

  foreach (var currentType in types)
  {
     if (!testmode)
     {
        // do something with this type that made the unittest fail and should be skipped.
     }
     // do something with this type (e.g: read it's attributes, process, etc).
  }
}

इन परिवर्तनों ने कोड को समझने के लिए अधिक विभेदक बना दिया क्योंकि आपने संभावित कोड-पथों की संख्या में वृद्धि की।

मैं कैसे और कब के साथ क्या मतलब है :

यदि आपके पास एक कार्यशील कार्यान्वयन है और "परीक्षण-क्षमताओं को लागू करने" की खातिर आपने बदलाव किए हैं, तो आपको अपने आवेदन का फिर से परीक्षण करना होगा क्योंकि आपने अपनी DoSomething()पद्धति को तोड़ दिया होगा ।

if (!testmode)समझने के लिए अधिक से अधिक difficulilt और निकाले विधि की तुलना में परीक्षण है।