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