आप कोड को टेस्ट-ड्राइव करना चाहते हैं, लेकिन आप अटके हुए हैं। हो सकता है आपको पूरी तरह से यकीन न हो कि आपके ऑब्जेक्ट का इंटरफेस कैसा दिखना चाहिए। हो सकता है आप किसी धूप भरे गर्मी के दिन से विचलित हों। आपको यकीन न हो कि आप जो बनाने की सोच रहे हैं उसे टेस्ट कर सकते हैं या नहीं। या आप टालमटोल कर रहे हों, क्योंकि अभी टेस्ट लिखने का मन नहीं कर रहा। जब आपका TDD करने का मन न हो, तो TDD के लाभ कैसे प्राप्त करें?
प्रोटोटाइपिंग, या फेंकने के लिए एक बनाना
"जहां एक नई सिस्टम अवधारणा या नई तकनीक का उपयोग किया जाता है, वहां एक सिस्टम को फेंकने के लिए बनाना पड़ता है, क्योंकि सबसे अच्छी योजना भी पहली बार में इसे सही करने के लिए सर्वज्ञ नहीं होती। इसलिए एक को फेंकने की योजना बनाएं; आप वैसे भी फेंकेंगे।" – फ्रेड ब्रूक्स
कभी-कभी, जब मैं एक नई फीचर शुरू करता हूं, तो मुझे अपने पहले टेस्ट लिखने के बारे में सोचकर लकवा सा महसूस होता है। API को कैसा दिखना चाहिए, कौन से पैटर्न और प्रैक्टिस सबसे उपयुक्त होंगे, और यह सब कैसे एक साथ फिट होगा, इस बारे में बहुत सारे निर्णय लेने होते हैं।
जब मैं इस तरह अटक जाता हूं तो मेरे पास शुरुआत करने के कुछ तरीके हैं। एक प्रोटोटाइप बनाना एक और तरीका है।
जब आप एक प्रोटोटाइप लिखते हैं, तो आपको इसे एक स्केच की तरह सोचना चाहिए। ब्रेनस्टॉर्म करें और चीजों को आजमाएं। अभी टेस्ट या TDD की परवाह न करें। इसके बजाय, उन निर्णयों का पता कोड के साथ लगाएं जिन्हें लेने में आपको कठिनाई हो रही है। कुछ पैटर्न आजमाएं, और देखें कि जो फीचर आप डिजाइन करने की कोशिश कर रहे हैं, उसमें कौन सा फिट बैठता है। पता लगाएं कि आपके ऐप के डगमगाने वाले हिस्से कहां हैं, क्या अधिक विचार की आवश्यकता है, और आप बिना किसी वास्तविक कारण के किस बात को लेकर चिंतित थे।
फिर, इसे फेंक दें और इसे फिर से बनाएं। इस बार, TDD और इस नए ज्ञान का उपयोग करके कि आप फीचर को सबसे अच्छे तरीके से कैसे बना सकते हैं।
आप जानते हैं कि जब आप गलती से git checkout -f चलाते हैं जब आपने कुछ लिखा होता है, और आपको ऐसा लगता है जैसे आपके पेट में लात मारी गई हो? लेकिन फिर आप सोचते हैं, इसे बनाना तो है ही, तो मुझे लगता है मैं इसे फिर से करूंगा, और यह पहली बार की तुलना में बहुत बेहतर निकलता है? प्रोटोटाइप को फिर से बनाने के साथ भी यही सच है। अब जब आपके पास कुछ ठोस विचार हैं कि फीचर कैसा दिख सकता है, तो उस फीचर को TDD करना बहुत आसान हो जाएगा।
रिवर्स TDD
क्या आप कभी ऐसी स्थिति में आए हैं जहां आप जानते हैं कि कुछ कैसे बनाना है, लेकिन आप नहीं जानते कि इसके लिए टेस्ट पहले कैसे लिखें? या शायद यह एक मेथड में एक लाइन का बदलाव है, लेकिन इसमें कुछ ट्वीकिंग की आवश्यकता हो सकती है, इसलिए आप इसे टेस्ट से लॉक नहीं करना चाहते जब तक कि आप नहीं जानते कि बदलाव वास्तव में कैसा दिखेगा?
इन स्थितियों में बहुत मदद करने वाली एक सरल प्रक्रिया है:
- बिना टेस्ट के कोड लिखें।
- कोड के लिए एक टेस्ट लिखें। सुनिश्चित करें कि यह पास होता है।
- कमेंट आउट करें जो कोड आपने लिखा था, या जिस फाइल में आपने कोड बदलाव किया था उसे रिवर्ट करें।
- टेस्ट को फिर से चलाएं। सुनिश्चित करें कि यह फेल होता है।
- कोड को फिर से लिखें। अपने टेस्ट चलाएं। सुनिश्चित करें कि वे पास होते हैं।
- कोड को रीफैक्टर करें, अपने नए टेस्ट का लाभ उठाते हुए।
मैं इसे रिवर्स TDD या ग्रीन-रेड-ग्रीन-रीफैक्टर के रूप में सोचता हूँ। आपको TDD का "टेस्ट-ड्रिवेन डिज़ाइन" हिस्सा नहीं मिलेगा, लेकिन आप तब भी देख पाएंगे कि जब आपका कोड टूटा होता है तो आपके टेस्ट फेल होते हैं। यह महत्वपूर्ण है, क्योंकि आप उन टेस्ट पर भरोसा नहीं कर सकते जो कम से कम एक बार फेल न हुए हों।
रिवर्स TDD आमतौर पर छोटे बदलावों के साथ सबसे अच्छा काम करता है जिन्हें अधिक डिज़ाइन की आवश्यकता नहीं होती। बगफिक्स सोचें, या ऐसे बदलाव जो एक लाइन, मेथड, या क्लास तक सीमित हों। लेकिन मैं इस तकनीक का बहुत उपयोग करता हूं, खासकर छोटे बदलावों के लिए जिनके साथ मैं अभी भी प्रयोग कर रहा हूं।
पेयरिंग गेम
पेयरिंग गेम आपके रेड-ग्रीन-रीफैक्टर रूटीन से बाहर निकलने का एक शानदार तरीका है जब आपके पास कोई दूसरा डेवलपर हो। यह इस तरह काम करता है:
- एक पार्टनर खोजें।
- आप एक ऐसा टेस्ट लिखें जो फेल होगा।
- आपका पार्टनर उस टेस्ट को पास करने के लिए सबसे सरल कोड लिखने की कोशिश करता है।
- आप एक और टेस्ट लिखें जो उस कोड पर फेल होगा।
- आपका पार्टनर कोड लिखता है जो उस टेस्ट को पास करेगा।
- दोहराएं…
- किसी बिंदु पर जब टेस्ट ग्रीन हों, तो आप टेस्ट लिखने के बजाय कुछ कोड रीफैक्टर करना चुन सकते हैं।
- रीफैक्टरिंग के बाद, टेस्टर और कोडर की भूमिकाएं बदल लें।
मैं आपको एक रहस्य बताता हूं: बॉलिंग स्कोर कैलकुलेटर पर पेयरिंग गेम खेलना ही वह तरीका था जिससे मैंने मूल रूप से TDD सीखा था। यह आपको फेल हो रहे टेस्ट के आधार पर सरल कोड लिखने का अभ्यास कराता है, और उन टेस्ट को लिखने का भी। दोनों डेवलपर्स एक-दूसरे की कोडिंग शैली और पसंदीदा तकनीकों के बारे में बहुत कुछ सीखेंगे। और आप लगभग तुरंत फ्लो हिट करेंगे, जिसका मतलब है कि जब आप खत्म करेंगे तो आपको बहुत अच्छा लगेगा।
आप शायद उतनी तेजी से कोड न लिख पाएं, लेकिन यह बहुत मजेदार है, और एक बेहतरीन सीखने का अनुभव है।
खेल बने रहें और प्रयोग करें
TDD को हठधर्मिता नहीं बनना चाहिए। कोर TDD अवधारणाओं के साथ खेलने के तरीके हैं जो आपको कुछ वास्तव में दिलचस्प जगहों पर ले जा सकते हैं। और आप और भी बेहतर कोड के साथ समाप्त हो सकते हैं।
इसलिए प्रयोग करें। कोड लिखने और TDD के नए दृष्टिकोण आजमाएं। देखें कि वे आपको कैसा महसूस कराते हैं, और आप किस तरह के कोड के साथ समाप्त होते हैं। और हर दिन किए जाने वाले काम में मज़ा और फ्लो को फिर से खोजते रहें।
