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