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