अच्छे डेवलपर्स जानते हैं कि उन्हें अपने कोड का टेस्ट करना चाहिए। लेकिन अक्सर, टेस्ट छोड़ दिए जाते हैं, जल्दबाजी में किए जाते हैं, या कभी शुरू ही नहीं होते। कुछ वास्तव में आम जाल हैं जिनमें मैंने लोगों को गिरते देखा है, और ये हर बार आपके टेस्ट करने के प्रेरणा को मार देंगे।
1. क्या मुझे RSpec उपयोग करना चाहिए? Cucumber? Capybara? Minitest?
जब आप एक नया प्रोजेक्ट शुरू करते हैं, तो बहुत आसान है बहुत समय यह तय करने में बिताना कि सबसे अच्छे टूल्स कौन से हैं। इस तरह की टालमटोल इस तथ्य को छुपाती है कि आप नहीं जानते कि कहां से शुरू करें, और जब तक आप अपने टूल्स नहीं चुनते, आप महसूस कर सकते हैं कि आप उत्पादक हैं बिना वास्तव में उत्पादक हुए।
इसके बजाय, बस उस स्टैक को चुनें जिसे आप सबसे अच्छी तरह जानते हैं। अगर आप किसी विशेष टेस्ट स्टैक के साथ अनुभवी नहीं हैं, तो डिफ़ॉल्ट लें - रेल्स जो देता है उससे शुरू करें। आप बाद में हमेशा और जोड़ सकते हैं। नए टूल्स आज़माने में कुछ गलत नहीं है, लेकिन ये बहुत बेहतर विचार है कि उन्हें समय के साथ पेश किया जाए, जैसे-जैसे आप अपने प्रोजेक्ट और वर्कफ्लो को बेहतर तरीके से जानते जाएं।
2. क्या मुझे यूनिट टेस्ट्स से शुरू करना चाहिए? फंक्शनल टेस्ट्स? इंटीग्रेशन टेस्ट्स?
जब आप एक प्रोजेक्ट शुरू करते हैं, तो आपके पास इस बात का अंदाजा होना चाहिए कि कौन सी फीचर्स या स्क्रीन्स पहले बननी चाहिए। ये शुरू करने के लिए एक बेहतरीन जगह है! अपनी फीचर लिस्ट से पहली चीज़ चुनें और उसके लिए एक फेलिंग इंटीग्रेशन टेस्ट लिखें। ये आपको बताएगा कि आप किस तरह के कंट्रोलर्स और रूट्स मिस कर रहे हैं, जिसका अर्थ है कि आपको कुछ फेलिंग फंक्शनल टेस्ट लिखने होंगे। कंट्रोलर्स को अपना काम करने के लिए डेटा और लॉजिक की आवश्यकता होती है, तो आप यूनिट टेस्ट्स और अपने मॉडल्स आगे लिखेंगे। फिर, एक बार जब आपके यूनिट टेस्ट पास हो जाते हैं, तो फंक्शनल टेस्ट पास होने चाहिए, और इंटीग्रेशन टेस्ट भी। अब आप अगली फीचर पर जा सकते हैं।
अगर आपके पास एक टेस्टिंग प्रोसेस है जिसमें हमेशा अगला चरण परिभाषित होता है, तो प्रेरित रहना बहुत आसान होता है। अगर आपको निर्णय नहीं लेने पड़ते, तो टालमटोल के घुसपैठ की कम गुंजाइश होती है।
3. मुझे नहीं पता कि इस नेटवर्क कोड, कमांड लाइन यूटिलिटी, या रेक टास्क को कैसे टेस्ट करूं!
यहां सबसे आसान काम ये है कि उस फाइल या क्लास से जितना संभव हो उतना कोड निकाल लें जिसे टेस्ट करना कठिन है, और इसे एक नए ऑब्जेक्ट में डाल दें जिसे टेस्ट करना आसान हो। इस तरह, टेस्ट करने में कठिन चीज़ बस आपके नए ऑब्जेक्ट को बनाती है और पैरामीटर्स पास करती है।
बेशक, आपके पास अभी भी वो मूल चीज़ है जिसे टेस्ट करना कठिन है। लेकिन अब ये शायद कोड की कुछ ही लाइनें हैं, और इसे स्टब या फेक आउट करना आसान होना चाहिए।
4. "प्रोजेक्ट लगभग हो गया, अब मुझे बस इसके लिए टेस्ट लिखने हैं!"
मैं जिस भी डेवलपर से मिला हूँ, वो कोड शिप करने की लालसा रखता है। अगर टेस्ट शिप करने से पहले करने वाली आखिरी चीज़ हैं, तो आप शायद आत्मविश्वास महसूस करने के लिए न्यूनतम संख्या में टेस्ट लिखेंगे। अगर आप इस आदत में पड़ जाते हैं, तो आप टेस्ट को मददगार के बजाय कष्टप्रद देखना शुरू कर देंगे, और खुद को उन्हें लिखने के लिए प्रेरित करना उतना ही कठिन होगा।
TDD के बारे में मेरी पसंदीदा चीजों में से एक ये है कि ये टेस्टिंग को डिज़ाइन और कोडिंग के साथ मिला देता है, जिसका अर्थ है कि आप टेस्टिंग को कोडिंग के रूप में देखना शुरू कर देते हैं, जो इसे बहुत अधिक मजेदार बनाता है (और आपको टेस्ट का लाभ बहुत पहले मिलता है)।
5. क्या होगा अगर मैं इसे गलत कर रहा हूँ?
रूबी कम्युनिटी कोड क्वालिटी, यूनिट टेस्टिंग, और ऑब्जेक्ट ओरिएंटेड डिज़ाइन सिद्धांतों को वास्तव में आगे बढ़ाने के लिए जानी जाती है। ये एक महान चीज़ है! दुर्भाग्य से, इसका मतलब है कि पहली कोशिश में 100% टेस्ट कवरेज के साथ परफेक्ट कोड शिप करने का भारी दबाव महसूस करना वास्तव में आम है।
ये प्रोजेक्ट शुरू करना वास्तव में कठिन बना देता है, विशेष रूप से ओपन सोर्स, जहां आप जानते हैं कि दूसरे लोग कोड देखेंगे। अगर वे देखते हैं कि ये सभी SOLID सिद्धांतों का पालन नहीं करता तो लोग क्या कहेंगे? लेकिन कुछ चीजें हैं जो मैंने सीखी हैं जिन्होंने मुझे इस दबाव से निपटने में मदद की है:
- हर अच्छा डेवलपर ऐसा कोड लिखता है जिसके लिए वे बाद में शर्मिंदा होते हैं।
- शिप होने वाला अच्छा कोड, शिप न होने वाले परफेक्ट कोड से अनंत रूप से बेहतर है।
- कुछ लोग बस झटके हैं और आपके कोड का मजाक उड़ाएंगे। ये वास्तव में बेकार है। इसने मेरे पूरे हफ्ते बर्बाद किए हैं। लेकिन अच्छे डेवलपर आपकी आलोचना करने के बजाय आपकी मदद करना चाहते हैं। और मैं शर्त लगाता हूँ कि अगर आप उस कोड को अपने किसी प्रोग्रामिंग हीरो को दिखाएंगे, तो वे उसका मजाक नहीं उड़ाएंगे - वे इसे बेहतर बनाने में आपकी मदद करेंगे।
आपने और क्या देखा है?
इनमें से किन जालों में आप फंसे हैं? आपको बाहर निकलने में क्या मदद मिली? और क्या कोई ऐसा है जिसका मैंने उल्लेख नहीं किया जिसे आपने देखा है?
अगर आप इनमें से किसी जाल में खुद को पहचानते हैं, तो आप खुद को बाहर निकालने के लिए क्या करने जा रहे हैं?
