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