नमस्कार, हेब्र!
एक लंबे समय के लिए और लगभग असफल, हम एक उज्ज्वल सिर की तलाश में हैं जो बाजार में श्री केंट बेक को बाहर करना चाहता है - अर्थात, हम किसी ऐसे व्यक्ति की तलाश कर रहे हैं जो हमारे लिए टीडीडी पर एक किताब लिखने के लिए तैयार है। वास्तविक उदाहरणों के साथ, आपके अपने शंकुओं और उपलब्धियों के बारे में एक कहानी। इस विषय पर बहुत कम पुस्तकें हैं, और आपने क्लासिक्स पर विवाद नहीं किया है ... शायद इसीलिए हम अभी तक इस प्रमुख से नहीं मिले हैं।
इसलिए, हमने न केवल खुद को फिर से याद दिलाने का फैसला किया कि हम ऐसे व्यक्ति की तलाश कर रहे थे, बल्कि एक विवादास्पद लेख का अनुवाद भी प्रस्तुत करने के लिए, जिसके लेखक डग अर्चुरी ने अपने विचार साझा किए कि क्यों टीडीडी मुख्यधारा नहीं बन पाया। आइए चर्चा करें कि क्या वह सही है, और यदि नहीं, तो क्यों।
यह परीक्षण के माध्यम से विकास का परिचायक नहीं है। यहां मैं इस अनुशासन को रिबूट करने के बारे में अपने विचार प्रस्तुत करूंगा और यूनिट परीक्षण की व्यावहारिक कठिनाइयों के बारे में बात करूंगा।दिग्गज प्रोग्रामर केंट बेक अपने आधुनिक अर्थों में TDD (परीक्षण के माध्यम से विकास) पद्धति के लेखक हैं। एरच गामा के साथ केंट ने भी, जेयूनिट के निर्माण में योगदान दिया, जो कि व्यापक रूप से इस्तेमाल किया जाने वाला परीक्षण ढांचा है।
अपनी
एक्सपी एक्सप्लेस्ड किताब (दूसरा संस्करण) में, केंट बताता है कि
मूल्यों और
प्रथाओं के प्रतिच्छेदन पर
सिद्धांत कैसे बनते हैं। यदि आप अवधारणाओं की एक सूची बनाते हैं और उन्हें एक प्रकार के सूत्र में स्थानापन्न करते हैं, तो आपको एक परिवर्तन मिलता है।
[KISS, Quality, YAGNI, ...] + [Testing, Specs, ...] == [TDD, ...]
मैं इस काम का गहराई से सम्मान करता हूं, जो केंट के लिए एक जीवन भर का काम है - न केवल प्रोग्रामिंग में अपनी उत्कृष्ट कृतियों के लिए, बल्कि इस तथ्य के लिए भी कि वह अथक रूप से
विश्वास ,
साहस ,
श्रेष्ठता ,
सरलता और
भेद्यता का सार
तलाशता है । ये सभी विशेषताएँ चरम प्रोग्रामिंग (एक्सपी) के आविष्कार के लिए अपरिहार्य थीं।
टीडीडी एक सिद्धांत और
अनुशासन है जो एक्सपी समुदाय में पालन किया जाता है। यह अनुशासन पहले से ही 19 साल पुराना है।
इस लेख में मैं अपनी राय साझा करूँगा कि TDD कैसे आत्मसात करने में कामयाब रहा। फिर मैं दिलचस्प व्यक्तिगत टिप्पणियों को साझा करूंगा जो मेरे टीडीडी सत्र के दौरान दिखाई दिए। अंत में, मैं यह समझाने की कोशिश करूंगा कि टीडीडी को उतना कठिन शूट क्यों नहीं करना चाहिए जितना कि यह लग रहा था। चलो चलते हैं।
टीडीडी, अनुसंधान और व्यावसायिकतापिछले 19 वर्षों से टीडीडी का अनुशासन प्रोग्रामिंग समुदाय में विवाद का विषय रहा है।
पहला सवाल जो एक पेशेवर विश्लेषक आपसे पूछेगा "क्या डेवलपर्स का प्रतिशत है जो आज टीडीडी का उपयोग करते हैं?" यदि आपने इस बारे में रॉबर्ट मार्टिन (अंकल बॉब) के मित्र और केंट बेक के मित्र से पूछा, तो उत्तर "100%" होगा।
बस अंकल बॉब को यकीन है कि
परीक्षण के माध्यम से विकास का अभ्यास नहीं करने पर अपने आप को पेशेवर मानना असंभव है ।
चाचा बॉब कई वर्षों से इस अनुशासन में शामिल रहे हैं, इसलिए इस समीक्षा में उन पर ध्यान देना स्वाभाविक है। चाचा बॉब ने टीडीडी का बचाव किया और इस अनुशासन की सीमाओं का काफी विस्तार किया। आप निश्चिंत हो सकते हैं कि अंकल बॉब और उनकी व्यावहारिक हठधर्मिता के लिए मेरे मन में अत्यंत सम्मान है।
हालाँकि, कोई भी निम्नलिखित प्रश्न नहीं पूछता है: "आखिरकार, अभ्यास करने का अर्थ है" जानबूझकर उपयोग करने के लिए "- लेकिन यह प्रतिशत, सही का न्याय करने की अनुमति नहीं देता है?" मेरे व्यक्तिपरक राय में, अधिकांश प्रोग्रामर किसी भी प्रतीकात्मक अवधि के लिए भी टीडीडी
के साथ सौदा नहीं करते थे।
वास्तविकता यह है कि हम वास्तव में इन नंबरों को नहीं जानते हैं, क्योंकि किसी ने भी इस प्रतिशत की सक्रिय रूप से जांच नहीं की है। सभी विशिष्ट डेटा
WeDoTDD वेबसाइट पर एकत्र कंपनियों के एक छोटे से चयन तक सीमित हैं। यहां आपको ऐसी कंपनियों के आंकड़े मिलेंगे, जो हर समय TDD का अभ्यास करती हैं, लेकिन यह सूची बड़ी नहीं है। इसके अलावा, यह अधूरा है, क्योंकि यहां तक कि एक सरल खोज से टीडीडी में शामिल अन्य बड़े संगठनों का पता चलता है - लेकिन, शायद, पूरी क्षमता से नहीं।
अगर हमें नहीं पता कि कितनी कंपनियां टीडीडी का अभ्यास करती हैं, तो निम्न प्रश्न उठता है: "टीडीडी कितना प्रभावी है, इसकी औसत दर्जे की योग्यता को देखते हुए"?
आप शायद प्रसन्न होंगे कि कई वर्षों से कई अध्ययन किए गए हैं जो टीडीडी की प्रभावशीलता की पुष्टि करते हैं। उनमें से निश्चित रूप से
Microsoft ,
IBM , उत्तरी कैरोलिना
विश्वविद्यालय और हेलसिंकी विश्वविद्यालय से आधिकारिक रिपोर्टें हैं।
हेलसिंकी विश्वविद्यालय की एक रिपोर्ट से लिया गया एक अभिव्यंजक आरेख।एक निश्चित सीमा तक, ये रिपोर्ट साबित करती हैं कि त्रुटि घनत्व 40-60% तक कम हो सकता है, जिसके लिए अधिक काम करने की आवश्यकता होती है; रनटाइम में 15-35% की वृद्धि होती है। इन संख्याओं को पहले से ही पुस्तकों और नई औद्योगिक विधियों में पता लगाया जा रहा है, विशेष रूप से DevOps समुदाय में।
आंशिक रूप से इन सवालों का जवाब देते हुए, हम पिछले एक की ओर मुड़ते हैं: "जब मैं टीडीडी का अभ्यास शुरू करूं तो मैं क्या गिन सकता हूं?" यह इस जवाब के लिए था कि मैंने टीडीडी की अपनी व्यक्तिगत टिप्पणियों को तैयार किया है। चलिए उन पर चलते हैं।
1. टीडीडी को एक मौखिक दृष्टिकोण की आवश्यकता होती हैटीडीडी का अभ्यास करते समय, हम "लक्ष्य पदनाम" की घटना का सामना करना शुरू करते हैं। सीधे शब्दों में कहें तो असफल और सफल परीक्षण तैयार करने जैसी संक्षिप्त परियोजनाएं डेवलपर के लिए एक गंभीर बौद्धिक चुनौती हैं। डेवलपर को स्पष्ट रूप से स्पष्ट करना होगा: "मेरा मानना है कि यह परीक्षण सफल होगा" और "मेरा मानना है कि यह परीक्षण विफल हो जाएगा" या "मुझे यकीन नहीं है, मुझे इस दृष्टिकोण की कोशिश करने के बाद मुझे प्रतिबिंबित करना चाहिए।"
आईडीई डेवलपर के लिए बन गया है कि रबर बतख जो सक्रिय रूप से उसके साथ बात करने के लिए भीख माँगती है। टीडीडी उद्यमों में कम से कम, इस तरह की बातचीत को एक निरंतर चर्चा में विलय करना चाहिए।
पहले सोचो - और फिर अपना अगला कदम (या कदम) उठाओ।
इस तरह के सुदृढीकरण संचार में एक महत्वपूर्ण भूमिका निभाता है: यह आपको न केवल अपने अगले कदम की भविष्यवाणी करने की अनुमति देता है, बल्कि आपको
सबसे सरल कोड लिखने के लिए उत्तेजित करता है जो यूनिट टेस्ट पास करने की अनुमति देता है। बेशक, अगर डेवलपर चुप है, तो वह निश्चित रूप से अपना कोर्स खो देगा, जिसके बाद उसे ट्रैक पर लौटना होगा।
2. टीडीडी मोटर मेमोरी को पंप करता हैडेवलपर, अपने पहले टीडीडी चक्रों के माध्यम से अपना रास्ता बना रहा है, जल्दी से थक जाता है - आखिरकार, यह प्रक्रिया असुविधाजनक है और लगातार स्टालों। यह किसी भी गतिविधि के साथ एक सामान्य स्थिति है जिसे कोई व्यक्ति अभी शुरू कर रहा है, लेकिन अभी तक कोई महारत हासिल नहीं है। डेवलपर अपने हाथ को भरने और मोटर मेमोरी में सुधार करने के लिए, इस चक्र को अनुकूलित करने की कोशिश करते हुए, शॉर्टकट का सहारा लेगा।
मज़ेदार होने और घड़ी की कल की तरह काम करने के लिए मोटर मेमोरी अपरिहार्य है। टीडीडी में, क्रियाओं की पुनरावृत्ति के कारण यह आवश्यक है।
इस तरह के शॉर्टकट के साथ धोखा पत्र प्राप्त करें। छोरों को प्रभावी बनाने के लिए अपने IDE में अपने कीबोर्ड शॉर्टकट का अधिकतम लाभ उठाएं। फिर देखते रहो।
कुछ ही सत्रों में, डेवलपर पूरी तरह से शॉर्टकट के चयन में महारत हासिल करता है, विशेष रूप से, कुछ सत्र एक परीक्षण स्टैंड को इकट्ठा करने और चलाने के लिए पर्याप्त हैं। जब आप नई कलाकृतियां बनाने, पाठ को उजागर करने और आईडीई के माध्यम से नेविगेट करने का अभ्यास करते हैं, तो यह सब आपको पूरी तरह से स्वाभाविक लगेगा। अंत में, आप एक सच्चे पेशेवर बन जाएंगे और सभी रीफैक्टरिंग तकनीकों में महारत हासिल करेंगे: विशेष रूप से, निकालने, नाम बदलने, उत्पन्न करने, सुधार और वंशीकरण।
3. टीडीडी को कम से कम अग्रिम में अपने कार्यों पर थोड़ा विचार करने की आवश्यकता होती हैजब भी कोई डेवलपर टीडीडी शुरू करने के बारे में सोचता है, तो उसे उन कार्यों के संक्षिप्त मानसिक मानचित्र को ध्यान में रखना होगा जिन्हें हल करने की आवश्यकता है। प्रोग्रामिंग के लिए पारंपरिक दृष्टिकोण में, ऐसा नक्शा हमेशा नहीं होता है, और कार्य को "मैक्रो स्तर पर" प्रस्तुत किया जा सकता है या अनुसंधान प्रकृति हो सकती है। हो सकता है कि डेवलपर समस्या को हल करने का तरीका नहीं जानता, लेकिन केवल लक्ष्य की कल्पना करता है। इस लक्ष्य के प्रति यूनिट परीक्षणों की उपेक्षा की जाती है।
काम पर बैठे और एक और "बैठ जाओ" के साथ समाप्त होने पर - इससे बाहर एक अनुष्ठान करने का भी प्रयास करें। पहले सोचें और सूची दें। इसके साथ खेलो। सूची और अधिक फिर आगे बढ़ें, करें, सोचें। मार्क। कई बार दोहराएं। फिर सोचें और रुकें।
काम के प्रति सजग रहें। ट्रैक पहले से ही किया गया है - बक्से की जाँच करें। कभी कम से कम एक होने तक मोड़ो। सोचो!
शायद सूची के शब्दों में कुछ समय लगेगा जो काम के चक्र में फिट नहीं होता है। हालाँकि, शुरू करने से पहले, आपके पास एक सूची होनी चाहिए। इसके बिना, आप नहीं जानते कि आप कहां जा रहे हैं। बिना कार्ड के कहीं नहीं।
// // "" -> // "a" -> // "aa" -> // "racecar" -> // "Racecar" -> // //
डेवलपर को केंट बेक द्वारा वर्णित
परीक्षणों की सूची देनी चाहिए। परीक्षण सूची आपको चक्र के रूप में समस्या को हल करने की अनुमति देती है जो आसानी से एक दूसरे में गुजरती हैं। परीक्षणों की सूची के ऊपर आपको लगातार प्रक्रिया और अद्यतन करने की आवश्यकता है, भले ही परीक्षण से कुछ सेकंड पहले। यदि परीक्षण सूची को अंतिम चरण में लगभग पूरी तरह से घटा दिया जाता है, तो परिणाम "लाल" होता है, और पूरी परीक्षा विफल हो जाती है।
4. टीडीडी सहकर्मियों के साथ संचार पर निर्भर करता हैउपरोक्त सूची पूरी होने के बाद, कुछ चरणों को अवरुद्ध किया जा सकता है, क्योंकि वे स्पष्ट रूप से वर्णन नहीं करते हैं कि क्या करना है। डेवलपर ने परीक्षणों की सूची को नहीं समझा। विपरीत भी होता है - सूची बहुत अधिक क्रूड है, जिसमें आवश्यकताओं के बारे में बहुत सारी धारणाएं हैं जो अभी तक तैयार नहीं हुई हैं। अगर आपको ऐसा कुछ मिलता है, तो तुरंत रोक दें।
टीडीडी के बिना कार्य करने के परिणामस्वरूप अत्यधिक जटिल कार्यान्वयन हो सकते हैं। टीडीडी की शैली में काम करते हैं, लेकिन बिना किसी सूची के, बिना किसी खतरनाक तरीके से काम करते हैं।
यदि आप देखते हैं कि परीक्षण सूची में अंतराल हैं, तो खड़े हो जाओ और जोर से कहो।
टीडीडी में, डेवलपर को यह समझना चाहिए कि मालिक की व्याख्या में आवश्यक आवश्यकताओं के विचार द्वारा निर्देशित किया जा रहा है कि क्या करना है - और कुछ भी नहीं। यदि इस संदर्भ में आवश्यकता स्पष्ट नहीं है, तो परीक्षणों की सूची अलग होने लगती है। इस विफलता पर चर्चा करने की आवश्यकता है। एक शांत चर्चा जल्दी विश्वास और सम्मान बनाने में मदद करती है। इसके अलावा, यह कैसे तेजी से प्रतिक्रिया लूप बनते हैं।
5. टीडीडी को पुनरावृत्त वास्तुकला की आवश्यकता हैअपनी एक्सपी पुस्तक के पहले संस्करण में वापस, केंट ने सुझाव दिया कि परीक्षण वास्तुकला के पीछे ड्राइविंग बल होना चाहिए। हालांकि, कई वर्षों के दौरान, कहानियों के बारे में सामने आया है कि स्प्रिंट टीमें कुछ स्प्रिंटों में पहले से ही एक दीवार पर कैसे ठोकर खाती हैं।
बेशक, परीक्षणों पर आधारित एक वास्तुकला का निर्माण तर्कहीन है। चाचा बॉब खुद अन्य विशेषज्ञों से सहमत थे कि यह अच्छा नहीं था। एक अधिक व्यापक मानचित्र की आवश्यकता है, लेकिन परीक्षण सूचियों से बहुत दूर नहीं है जिन्हें आपने "क्षेत्र में" विकसित किया है।
कई साल बाद, केंट ने अपनी पुस्तक
TDD बाय उदाहरण में इस थीसिस को आवाज़ दी।
प्रतिस्पर्धा और
सुरक्षा दो मुख्य क्षेत्र हैं जहां टीडीडी ड्राइविंग बल नहीं हो सकता है, और डेवलपर को उनके साथ अलग से निपटना चाहिए। हम कह सकते हैं कि प्रतिस्पर्धा प्रणाली के डिजाइन का एक अलग स्तर है, प्रतिस्पर्धा को पुनरावृत्तियों द्वारा विकसित करने की आवश्यकता है, इस प्रक्रिया को टीडीडी के साथ समन्वयित करना। यह आज विशेष रूप से सच है, जैसा कि कुछ आर्किटेक्चर एक
प्रतिक्रियाशील प्रतिमान और प्रतिक्रियाशील एक्सटेंशन की ओर विकसित हो रहे हैं (
प्रतिक्रिया अपने चरम पर प्रतिस्पर्धात्मकता है)।
पूरे संगठन का एक बड़ा नक्शा बनाएँ। चीजों को थोड़ा परिप्रेक्ष्य में देखने में मदद करना। सुनिश्चित करें कि आप और टीम एक ही पाठ्यक्रम में आगे बढ़ रहे हैं।
हालांकि, सबसे महत्वपूर्ण विचार पूरे सिस्टम का संगठन है, और एक टीडीडी संगठन प्रदान नहीं किया गया है। तथ्य यह है कि इकाई परीक्षण एक निम्न-स्तरीय चीज है। पुनरावृत्ति वास्तुकला और टीडीडी ऑर्केस्ट्रेशन अभ्यास में जटिल हैं और सभी टीम के सदस्यों, जोड़ी प्रोग्रामिंग और ठोस कोड समीक्षाओं के बीच विश्वास की आवश्यकता होती है। यह पूरी तरह से स्पष्ट नहीं है कि इसे कैसे प्राप्त किया जाए, लेकिन जल्द ही आप देख सकते हैं कि विषय क्षेत्र में परीक्षण सूचियों के कार्यान्वयन के साथ संक्षिप्त डिजाइन सत्र का आयोजन किया जाना चाहिए।
6. टीडीडी इकाई परीक्षणों की नाजुकता और कार्यान्वयन को कम करता हैयूनिट परीक्षणों में एक मजेदार विशेषता है, और टीडीडी इसे पूरी तरह से दूर कर देता है। वे सही साबित करने की अनुमति नहीं देते हैं। E.V.Dijkstra ने इस समस्या पर काम किया और चर्चा की कि इस मामले में गणितीय प्रमाण कैसे संभव है जो इस अंतर को भर देगा।
उदाहरण के लिए, निम्नलिखित उदाहरण में, व्यापारिक तर्क द्वारा निर्देशित एक काल्पनिक अपूर्ण पैलिंड्रोम से संबंधित सभी परीक्षण हल किए जाते हैं। एक उदाहरण TDD पद्धति का उपयोग करके विकसित किया गया है।
// @Test fun `Given "", then it does not validate`() { "".validate().shouldBeFalse() } @Test fun `Given "a", then it does not validate`() { "a".validate().shouldBeFalse() } @Test fun `Given "aa", then it validates`() { "aa".validate().shouldBeTrue() } @Test fun `Given "abba", then it validates`() { "abba".validate().shouldBeTrue() } @Test fun `Given "racecar", then it validates`() { "racecar".validate().shouldBeTrue() } @Test fun `Given "Racecar", then it validates`() { "Racecar".validate().shouldBeTrue() }
दरअसल, इन परीक्षणों में खामियां हैं। सबसे तुच्छ मामलों में भी यूनिट परीक्षण नाजुक हैं। उनकी शुद्धता को साबित करना कभी संभव नहीं था, क्योंकि अगर हमने कोशिश की तो उसे अविश्वसनीय मानसिक कार्य की आवश्यकता होगी, और इसके लिए आवश्यक इनपुट की कल्पना करना असंभव होगा।
// , fun String.validate() = if (isEmpty() || length == 1) false else toLowerCase() == toLowerCase().reversed() // , fun String.validate() = length > 1 length > 1
length > 1 को
पतित कार्यान्वयन कहा जा सकता
है । यह कार्य को हल करने के लिए पर्याप्त है, लेकिन स्वयं उस समस्या के बारे में कुछ भी रिपोर्ट नहीं करता है जिसे हम हल करने का प्रयास कर रहे हैं।
सवाल है - एक डेवलपर को परीक्षण लिखना कब बंद करना चाहिए? उत्तर सरल लगता है: जब यह
व्यापारिक तर्क के दृष्टिकोण से पर्याप्त है , और कोड के लेखक के अनुसार नहीं। यह हमारे
डिजाइन जुनून को चोट पहुंचा सकता है, और सादगी
लोगों को
परेशान कर सकती
है । इन भावनाओं की भरपाई हमारे अपने साफ-सुथरे कोड को देखने और बाद में समझ में आने वाले कोड से आत्मविश्वास से की जा सकती है। सभी कोड बहुत साफ-सुथरे होंगे।
ध्यान दें कि सभी अविश्वसनीयता के लिए, यूनिट परीक्षण आवश्यक हैं। उनकी ताकत और कमजोरियों को समझें। यदि पूरी तस्वीर नहीं जुड़ती है, तो शायद यह अंतर
म्यूटेशन परीक्षण को भरने में मदद करेगा।
टीडीडी के अपने फायदे हैं, लेकिन यह पद्धति हमें अनावश्यक रेत महल बनाने से विचलित कर सकती है। हां, यह एक
सीमा है , लेकिन इसके लिए धन्यवाद, आप तेजी से, आगे और अधिक मज़बूती से आगे बढ़ सकते हैं। शायद यह अंकल बॉब के दिमाग में यह था कि क्या वर्णन करते समय, उनके दृष्टिकोण से, इसका मतलब
पेशेवर होना है ।
लेकिन! कोई फर्क नहीं पड़ता कि इकाई परीक्षण हमें कितने नाजुक लगते हैं, वे एक नितांत आवश्यक हैं। यह वह है जो
डर को
साहस में बदल
देता है। टेस्ट कोमल कोड प्रदान करता है; इसके अलावा, वे किसी भी नए डेवलपर के
लिए एक
मार्गदर्शक और
दस्तावेज के रूप में काम कर सकते हैं, जो परियोजना के लाभ के लिए तुरंत ट्रैक और काम कर सकते हैं - यदि यह परियोजना अच्छी तरह से इकाई परीक्षणों द्वारा कवर की गई है।
7. टीडीडी परीक्षण कथनों के रिवर्स लूप को प्रदर्शित करता हैएक कदम आगे बढ़ाओ। निम्नलिखित दो घटनाओं को समझने के लिए, हम अजीब आवर्ती घटनाओं का अध्ययन करते हैं। आरंभ करने के लिए, आइए FizzBuzz पर एक त्वरित नज़र डालें। यहाँ हमारे परीक्षणों की सूची है।
// 9 15. [OK] // , 3, Fizz . // ...
हम कुछ कदम आगे बढ़े। अब हमारा टेस्ट फेल हो गया।
@Test fun `Given numbers, replace those divisible by 3 with "Fizz"`() { val machine = FizzBuzz() assertEquals(machine.print(), "?") } class FizzBuzz { fun print(): String { var output = "" for (i in 9..15) { output += if (i % 3 == 0) { "Fizz " } else "${i} " } return output.trim() } } Expected <Fizz 10 11 Fizz 13 14 Fizz>, actual <?>.
स्वाभाविक रूप से, यदि हम
assertEquals डेटा में
assertEquals डेटा की नकल करते हैं, तो वांछित परिणाम प्राप्त होता है, और परीक्षण किया जाता है।
कभी-कभी असफल परीक्षण, परीक्षा पास करने के लिए आवश्यक सही परिणाम देते हैं। मुझे नहीं पता कि इस तरह के आयोजनों को क्या नाम दिया जाए ... शायद
वूडू परीक्षण । यह देखने के लिए आप कितनी बार होते हैं - आंशिक रूप से परीक्षण करते समय आपके आलस्य और शिष्टाचार पर निर्भर करता है, लेकिन मैंने कई बार ऐसी चीजों पर ध्यान दिया है जब कोई व्यक्ति कार्यान्वयन प्राप्त करने की कोशिश करता है जो सामान्य रूप से तैयार और अनुमानित डेटा सेट के साथ काम करता है।
8. टीडीडी परिवर्तनों का क्रम दिखाता हैटीडीडी आपको फंसा सकता है। ऐसा होता है कि डेवलपर स्वयं द्वारा किए गए परिवर्तनों में भ्रमित हो जाता है, जिसका उपयोग वह वांछित कार्यान्वयन को प्राप्त करने के लिए करता है। कुछ बिंदु पर, परीक्षण कोड एक अड़चन में बदल जाता है जहां हम स्टाल करते हैं।
एक
मृत अंत रूपों। डेवलपर को इस जाल से बाहर निकलने के लिए कुछ परीक्षणों को हटाते हुए, पीछे हटना और निरस्त्रीकरण करना पड़ता है। डेवलपर असुरक्षित रहता है।
चाचा बॉब के अपने कैरियर के वर्षों में इस तरह के गतिरोधों में पड़ने की संभावना थी, जिसके बाद उन्हें स्पष्ट रूप से पता चला कि परीक्षण पास करने के लिए, उन्हें एक मृत अंत में होने की संभावना को कम करने के लिए सही अनुक्रम सेट करना था। इसके अलावा, उसे एक और शर्त का एहसास करना था।
जितने अधिक विशिष्ट परीक्षण होते हैं, उतना ही सामान्यीकृत कोड होता है ।
परिवर्तनों का क्रम। आपको हमेशा सबसे सरल विकल्प (सूची के शीर्ष पर) के लिए प्रयास करना चाहिए।यह
संक्रमण प्राथमिकता शर्त है । जाहिरा तौर पर, रिफैक्टिंग के जोखिम का एक निश्चित क्रम है, जिसे हम परीक्षण पास करने तक पहुंचने के लिए तैयार हैं। आमतौर पर सूची के सबसे ऊपर (सबसे सरल) में दिखाए गए रूपांतरण विकल्प को चुनना सबसे अच्छा है - इस मामले में, एक मृत अंत में आने की संभावना न्यूनतम रहती है।
टीपीपी या
अंकल बॉब का टेस्ट विश्लेषण , तो बोलने के लिए, सबसे पेचीदा, तकनीकी और रोमांचक घटनाओं में से एक है जो वर्तमान में मनाया जाता है।
अपने कोड को यथासंभव सरल रखने के लिए इसका उपयोग करें।
टीपीपी सूची का प्रिंट आउट लें और इसे अपने डेस्क पर रखें। मृत सिरों में जाने से बचने के लिए उसके साथ की जाँच करें। इसे नियम बनाएं: आदेश सरल होना चाहिए।
यह मेरी प्राथमिक टिप्पणियों की कहानी को समाप्त करता है। हालांकि, लेख के अंतिम भाग में, मैं उस प्रश्न पर वापस लौटना चाहूंगा जिसे हम शुरुआत में जवाब देना भूल गए थे: "आज TDD का उपयोग करने वाले पेशेवर प्रोग्रामर का प्रतिशत क्या है?" मैं जवाब दूंगा: "मुझे लगता है कि उनमें से कुछ हैं।" मैं नीचे इस प्रश्न की जांच करना चाहूंगा और यह बताने का प्रयास करूंगा कि क्यों।
क्या टीडीडी व्यवहार में है?दुर्भाग्य से, नहीं। विशेष रूप से, ऐसा लगता है कि इसके समर्थकों का प्रतिशत कम है, और मैं डेटा खोजना जारी रखता हूं। भर्ती, टीम नेतृत्व और आत्म-विकास (जो मुझे मोहित करता है) में मेरा अनुभव मुझे निम्नलिखित टिप्पणियों को बनाने की अनुमति देता है।
कारण 1: वास्तविक परीक्षण संस्कृति के साथ संपर्क का अभावमैं यथोचित मान सकता हूं कि अधिकांश डेवलपर्स को वास्तविक
परीक्षण संस्कृति में सीखने और काम करने का अवसर नहीं मिला।
परीक्षण संस्कृति एक ऐसा वातावरण है जिसमें डेवलपर्स परीक्षण की कला में जानबूझकर अभ्यास और सुधार करते हैं। वे लगातार उन सहयोगियों को प्रशिक्षित करते हैं जिनके पास अभी भी इस क्षेत्र में पर्याप्त अनुभव नहीं है। प्रतिक्रिया प्रत्येक जोड़ी और प्रत्येक पूल अनुरोध में स्थापित की गई है जो सभी प्रतिभागियों को परीक्षण कौशल विकसित करने में मदद करता है। इसके अलावा, इंजीनियरों के पदानुक्रम में गंभीर समर्थन और कोहनी की भावना है। सभी प्रबंधक परीक्षण के सार को समझते हैं और उस पर विश्वास करते हैं। जब समय सीमा समाप्त होने लगती है, तो परीक्षण अनुशासन को नहीं छोड़ा जाता है, लेकिन इसका पालन किया जाता है।
जो लोग इस तरह के परीक्षण संस्कृति में खुद का परीक्षण करने के लिए भाग्यशाली थे, उदाहरण के लिए, मुझे ऐसी टिप्पणियों को बनाने का मौका मिला। .
2:TDD, ,
xUnit Patterns Effective Unit Testing . , -, , , . .
. , . . , , , … .
3:: , , . , , ; - , – .
4:, , TDD . , .
, , : « , ». : , « » — .
– .
निष्कर्षXP –
,
. – , . TDD.
, , . «» , , – , .
XP Explained. , , ., - .
, – , . , , , .
, , , .
TDD « » , . TDD . TDD .
. TDD , . TDD — , , . , TDD , . , .
@Test fun `Given software, when we build, then we expect tests`() { build(software) shoudHave tests }
, TDD – ,
,
. . , , , .