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