टीडीडी के व्यावहारिकता

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

व्यावहारिकता।

तो जब मैं टीडीडी का उपयोग नहीं करता हूं?

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

• सामान्य तौर पर, मैं कोड के लिए परीक्षण नहीं लिखता हूं जो मुझे परीक्षण और त्रुटि से "रासायनिक" करना है। लेकिन मैं इस तरह के "रसायन विज्ञान" को उस कोड से अलग करता हूं जिसमें मुझे यकीन है
• कभी-कभी, मैं थोड़ा अधिक कोडी हूं, फिर मैं इस पर परीक्षण लिखता हूं।
• इसके अलावा, कभी-कभी, मैं उस कोड को हटा देता हूं जिसके साथ मैं पहले से ही "रासायनिक" कर चुका हूं और इसे TDD तरीके से फिर से लिखता हूं।
• ऐसी स्थितियों में आपको क्या करना चाहिए, यह स्वाद का विषय है।

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

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

यह सब हठधर्मिता नहीं है।

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

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