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