आपको अब सब कुछ क्यों छोड़ना चाहिए और यूनिट टेस्ट लिखना शुरू करना चाहिए

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

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

आपको कंपाइलर की आवश्यकता क्यों है?

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

मुझे क्या मिल रहा है?

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

class Darth { public void FeelForce() { ... } public void DoHeavyBreath() { ... } } class Luke : Darth { public void DefeatAllEnemies() { ... } } void main() { Luke luke = new Luke(); luke.FeelForce(); luke.DefeatAllEnemies(); luke.DoHeavyBreath(); // ,   ,     } 

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

अधिक साक्षरता के लिए ऊपर दिए गए कोड को इस तरह दोबारा लिखा जाना चाहिए:

 abstract class Jedi { public void FeelForce() { ... } public virtual void DefeatAllEnemies() { throw new NotImplementedException(); } public virtual void DoHeavyBreath() { throw new NotImplementedException(); } } class Darth : Jedi { override void DoHeavyBreath() { ... // do heavy breath } } class Luke: Jedi { override void DefeatAllEnemies() { ... // defeat all enemies } } void main() { Luke luke = new Luke(); luke.FeelForce(); luke.DefeatAllEnemies(); luke.DoHeavyBreath(); } 

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

 void test_that_luke_cannot_do_heavy_breath() { try { main(); } catch(NotImplementedException ex) { Assert.Fail("Unimplemented method was called!"); } } 

मैं व्यक्तिगत रूप से इस दृष्टिकोण में देखता हूं कि उच्च-स्तरीय आर्किटेक्चर की जटिलता का मुकाबला करने के लिए एक उपकरण से ज्यादा कुछ नहीं है। मस्तिष्क की अपनी सीमा होती है, जिसे वह कवर कर सकता है, और आवश्यक उपकरण इन सीमाओं का विस्तार करते हैं। अमूर्तता के उच्च स्तर पर, कंपाइलर "त्रुटियों के सूचक" के रूप में अपनी भूमिका खो देता है, क्योंकि यह त्रुटियों के थोक को कवर नहीं कर सकता है। टीडीडी सक्षम है। बेशक, तकनीक अभी भी विकसित की जाएगी। आदर्श रूप से, डेवलपर को परियोजना को संकलित करने से पहले सभी मौजूदा बग्स (तार्किक वाले सहित) को जानना चाहिए, उन्हें मौजूदा और भविष्य के टूल द्वारा मदद की जाएगी, जिसके साथ टीडीडी मुख्य रूप से जुड़ा हुआ है। इस विकास पर भी ध्यान दिया जा सकता है। जो लोग रुचि रखते हैं वे Visual Studio के लिए NCrunch के बारे में पढ़ सकते हैं। मुझे लगता है कि अन्य आईडीई के लिए ऐसे उपकरण भी उपलब्ध हैं जो निरंतर परीक्षण से संबंधित हैं। संक्षेप में - यह उपकरण पृष्ठभूमि में हर समय इकाई परीक्षण चलाता है और आप तुरंत परीक्षा परिणाम देखते हैं क्योंकि आप पुन: जमा किए बिना कोड लिखते हैं। आप कुछ समानताओं को देखेंगे कि कैसे पृष्ठभूमि में संकलक वाक्यविन्यास त्रुटियों के लिए खोज करता है और जैसा वह पाता है वैसा ही उत्पन्न होता है। और अब उपकरण इतने स्मार्ट हो गए हैं कि वे तार्किक त्रुटियाँ भी दिखाते हैं। बेशक, आप इस असंतोष को इस तथ्य के साथ व्यक्त कर सकते हैं कि आपको अभी भी खुद को परीक्षण लिखना है और आप किसी प्रकार की तार्किक त्रुटि की दृष्टि खो सकते हैं, लेकिन मुझे लगता है कि यह अभी भी आगे है। शायद कुछ समय के परीक्षण खुद को व्यावसायिक तर्क के कुछ औपचारिक विवरण से उत्पन्न होंगे। किसी भी मामले में, जो नहीं है उसके लिए रोने से बेहतर है कि क्या है, आनन्दित हों।