मुझे क्यों नहीं लगता कि टीडीडी आवश्यक है

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

लेकिन जैसे-जैसे समय बीतता गया, मैं इसे एक अलग रोशनी में देखता हूं।

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

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

अच्छा

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

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

विचार मध्य में छिपे हुए चर के साथ समीकरण का निर्माण करना है। फिर कोडिंग समीकरण में भरने लगती है। ऐसे मामलों में यह बहुत सुविधाजनक है। कोडिंग रिक्त स्थान भरती है।

खराब

"टेस्ट ड्रिवेन डेवलपमेंट डबल एंट्री बहीखाता पद्धति है । वही अनुशासन। वही तर्क। वही परिणाम। -अंकल बॉब मार्टिन

मैं तर्क दूंगा कि परीक्षण डबल-एंट्री बहीखाता पद्धति जैसा है। हाँ। हमारे पास परीक्षण होना चाहिए। सवाल यह है कि क्या हमें अपने परीक्षणों के आधार पर अपना कोड बनाना चाहिए या इसके विपरीत? यहाँ उत्तर इतना सरल नहीं है।

यदि हमारे पास परीक्षणों के साथ पहले से मौजूद प्रणाली है, तो टीडीडी दुनिया में सभी समझ में आता है। लेकिन एक ऐसी प्रणाली का परीक्षण करना जो अभी तक निर्मित नहीं हुई थी। कुछ मामले ऐसे होते हैं जहां यह समझ में आता है, लेकिन उतनी बार नहीं जितना कोई सोचता है।

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

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

लेकिन असली समस्या धीमी प्रगति थी। कंपनी तेजी से आगे नहीं बढ़ सकी। टीडीडी समर्थकों को यह टिप्पणी करने में जल्दी होगी कि एक टीडीडी परियोजना रिफैक्टर करना आसान है क्योंकि परीक्षण हमें गारंटी देते हैं कि हमारे पास प्रतिगमन नहीं होगा। लेकिन यह इस तथ्य के बाद किए गए परीक्षण वाली परियोजनाओं पर लागू होता है।

बदतर

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

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

नतीजतन, टीडीडी आवश्यक एकीकरण परीक्षणों पर "अच्छा है" इकाई परीक्षणों पर अधिक जोर देता है। हाँ, आपके पास दोनों होना चाहिए। लेकिन मेरे पास एकीकरण परीक्षण होना चाहिए। वे TDD प्रक्रिया में उतनी सफाई से फिट नहीं होते हैं।

सही संचालित परीक्षण

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

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

खराब स्वचालन

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

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

हम शायद 80% परीक्षण की गई कार्यक्षमता को पार कर सकते हैं, लेकिन स्वचालन के लिए कम रिटर्न का एक बिंदु है। उन वातावरणों में टीडीडी समस्याग्रस्त है। कार्यक्षमता आसान है लेकिन परीक्षण बनाना अस्थिर हो जाता है।

आखिरकार

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

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

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

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

यहाँ भी प्रकाशित हुआ।