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