टीडीडी का अध्ययन क्यों मुश्किल है और इसके बारे में क्या करना है। भाग २

जारी रखा जाए। यहां से शुरू करें ।

यह सब कैसे उपयोग करें?

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

लिखने के लिए क्या परीक्षण?

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

टीडीडी का अध्ययन करते समय मुझे व्यक्तिगत रूप से सबसे अधिक संघर्ष करना पड़ा, वास्तविक उदाहरणों में टीडीडी का उपयोग करने के लिए सरल उदाहरणों से संक्रमण था। पदानुक्रम में निम्न वर्ग के लिए एक परीक्षण का चयन, मुझे परिणामी कोड को परियोजना में वापस डालने में कठिनाई हो रही थी। यहां समस्या यह थी कि मैंने परीक्षणों के बारे में नहीं सोचा था कि यह पता लगाने का एक तरीका है कि मुझे वास्तव में क्या चाहिए। और केवल परीक्षण का उपयोग करते समय जो समस्या के समाधान का वर्णन करता है, हमें वास्तव में उपयोगी सार मिला। चाल परीक्षण बनाने के लिए है जो वर्तमान समस्या का ज्ञान encapsulate करता है।

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

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

लेकिन आपने केवल परीक्षण बनाए बिना कोड लिखा था!

यह आसान है। TDD कोड फीडबैक प्रदान करता है। जब आप पहले से ही जानते हैं कि आपको क्या चाहिए (उदाहरण के लिए, यदि काम समाप्त वास्तुकला में छोटे हिस्से को जोड़ना है), तो डिजाइन के लिए जिम्मेदार TDD का हिस्सा ज्यादा फायदा नहीं देता है। यहां पूर्व-लेखन परीक्षणों का एकमात्र लाभ यह है कि आप यह सुनिश्चित कर सकते हैं कि वे शुरू में काम नहीं करते हैं; यह खुद को परीक्षण करने का एक तरीका है। इस मामले में, "पहला परीक्षण" दृष्टिकोण डिजाइन के बजाय परीक्षणों द्वारा कवर कोड बनाने की एक तकनीक है।

कम अज्ञात, उन्हें खोजने के लिए कम परीक्षणों की आवश्यकता होती है और अधिक से अधिक कदम आप स्थानांतरित कर सकते हैं।

यहां फिर से - एमवीवीएम पैटर्न का उपयोग करते हुए, आपने प्रारंभिक परीक्षण के बिना एक दृश्य बनाया!

हमने पहले ही यह जान लिया था कि टीडीडी वर्तमान कार्य को सीमित करता है, साथ ही यह समझने का अवसर प्रदान करता है कि इसका समाधान कितना अच्छा है। बेशक, टीडीडी पहले और दूसरे दोनों को प्राप्त करने के एकमात्र तरीके से दूर है। प्रस्तुति प्रौद्योगिकियाँ (WPF, MVC चौखटे, GTK, WebForms, आदि) अपने आप में UI के साथ बातचीत के संदर्भ में कोड पर महत्वपूर्ण प्रतिबंध लगाती हैं।

एमवीवीएम जैसे प्रस्तुति हाइलाइटिंग पैटर्न का उपयोग करते समय, हम किसी भी परीक्षण के बिना ViewModel के लिए आवश्यक गुणों और आदेशों को परिभाषित कर सकते हैं। हम ग्राहक के साथ चर्चा के दौरान काम करने के लिए चुने गए इंटरफ़ेस निर्माण तकनीक, साथ ही बाहरी डिजाइन द्वारा सीमित हैं (जो एक त्वरित प्रतिक्रिया प्रदान करने वाला उपकरण भी है)।

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

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

मैं फंस गया हूँ! परीक्षणों में फंस गया और पता नहीं क्या करना है ...

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

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

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

TDD? BDD? ATDD? मुझे वास्तव में क्या चाहिए?

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

सामान्य तौर पर, कोई भी एक सच्चा जवाब नहीं है। मुख्य लक्ष्य उस कोड से प्रतिक्रिया प्राप्त करना है जो वर्तमान में काम किया जा रहा है।

निष्कर्ष

हालांकि TDD प्रक्रिया के निर्देश सरल हैं, तकनीक स्वयं नहीं है। निर्देश शुरुआत में केवल सबसे छोटी सहायता प्रदान करते हैं, जबकि टीडीडी के चारों ओर प्रचार पूरी तरह से अवास्तविक अपेक्षाएं पैदा करता है।

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

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

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

डिजाइनिंग हमेशा कठिन होती है। टीडीडी आपको डिज़ाइन पर ध्यान केंद्रित करने और समझने का तरीका देता है कि इसे बेहतर कैसे बनाया जाए।

मुझे उम्मीद है कि ये विचार टीडीडी पर एक अलग दृष्टिकोण खोलते हैं और इस तकनीक को सीखने की प्रक्रिया को आसान बनाते हैं। टीडीडी प्रयास के लायक है। सौभाग्य!