टेस्ट-ड्रिवन डेवलपमेंट (कभी-कभी इसे टेस्ट-फर्स्ट डेवलपमेंट या टेस्ट-ड्रिवन डिज़ाइन भी कहा जाता है) वह तरीका है जिसमें आप इम्प्लीमेंटेशन कोड की एक भी लाइन लिखने से पहले यूनिट टेस्ट लिखते हैं।
Exercism पर टेस्ट ही असल आवश्यकताएँ हैं!
आप जिन भी प्रैक्टिस अभ्यासों पर काम करते हैं (यानी वे अभ्यास जो आपको कोई नया कॉन्सेप्ट नहीं सिखाते), उन सबके साथ कुछ निर्देश होते हैं, जो सामान्य शब्दों में बताते हैं कि आपको क्या करना है।
ये निर्देश जानबूझकर किसी खास प्रोग्रामिंग भाषा की इम्प्लीमेंटेशन बारीकियों को ध्यान में नहीं रखते, क्योंकि Exercism के 70 से अधिक भाषा ट्रैक इन्हीं निर्देशों को साझा करते हैं।
कुछ भाषा ट्रैक आपके लिए और ज़्यादा विस्तृत जानकारी भी जोड़ देते हैं, लेकिन सभी ऐसा नहीं करते।
जब आप किसी प्रैक्टिस अभ्यास पर काम शुरू करते हैं, तो निर्देशों को ध्यान से पढ़िए।
इनसे आपको एक मोटा अंदाज़ा मिल जाएगा कि हल किस तरह बनाना है।
लेकिन पूरी और सटीक आवश्यकताएँ समझने के लिए आपको टेस्ट पढ़ने होंगे:
- क्या परिणाम किसी खास तरह का डेटा स्ट्रक्चर होना चाहिए?
- क्या परिणाम किसी खास क्रम में लगा होना चाहिए?
- एक्सेप्शन संभालने के लिए आपसे क्या अपेक्षा है? और ऐसी ही कई बातें।
जब दिए गए सारे टेस्ट चलकर पास हो जाएँ, तभी मानिए कि आपने अभ्यास हल कर लिया।
दूसरे शब्दों में, आपका हल निर्देशों की कोई ऐसी व्याख्या भर नहीं है जो "सही लगती" हो; आपका हल एक ऐसा प्रोग्राम है जो दिए गए टेस्ट पूरे करता है।
टेस्ट ही किसी अभ्यास की पूरी आवश्यकताएँ दर्शाते हैं।
Exercism TDD को कैसे लागू करता है?
यूनिट टेस्ट सूट लिखने का काम हमने आपके लिए पहले ही कर दिया है।
आपका लक्ष्य है ऐसा हल लिखना जिसमें उतना ही कोड हो, जितना उन सारे यूनिट टेस्ट को पास कराने के लिए ज़रूरी है।
यह बात ध्यान में रखिए: TDD का तरीका आपको हल तक पहुँचने में मदद करेगा, लेकिन आपको वहीं रुकने की ज़रूरत नहीं है।
अगर आप अपने हल को आवश्यकताओं से आगे तक ले जाना चाहें, तो आप ऐसा कर सकते हैं।
अगर आप किसी मेंटर के साथ काम करना चुनें (और हमारा सुझाव है कि टेस्ट पास हो जाने के बाद आप ज़रूर ऐसा कीजिए), तो वे आपके शुरुआती इम्प्लीमेंटेशन को रीफैक्टर करने और बेहतर बनाने में मदद कर सकते हैं, या नए यूनिट टेस्ट सुझा सकते हैं।
ऑनलाइन एडिटर में काम करना
जब आप Exercism की वेबसाइट पर कोड एडिटर में काम कर रहे होते हैं, तो आप टेस्ट पढ़ सकते हैं, पर उन्हें बदल नहीं सकते।
हर बार चलाने पर सारे टेस्ट चलाए जाते हैं, चाहे टेस्ट फाइल में "skip" की कोई भी व्यवस्था लिखी हो।
जब कई टेस्ट फेल होते हैं, तो वेबसाइट शुरू में सिर्फ पहले फेल हुए टेस्ट का परिणाम दिखाती है।
आप बाकी फेल हुए टेस्टों पर क्लिक करके उन्हें खोल भी सकते हैं!
कभी-कभी पहला परिणाम सबसे ज़्यादा जानकारी देने वाला नहीं होता।
बहुत सारे टेस्ट फेल होने पर हिम्मत मत हारिए।
एक-एक करके उन्हें पास कराने पर ध्यान दीजिए।
अपने कंप्यूटर पर काम करना
कई ट्रैक अपनी टेस्ट फाइलों में "skip" किए गए टेस्ट रखते हैं।
शुरू में सिर्फ पहला टेस्ट "सक्रिय" होता है और बाकी "निष्क्रिय" रहते हैं (ऐसा कैसे होता है, यह ट्रैक के हिसाब से बदलता है)।
जब आप अपने वातावरण में टेस्ट सूट चलाते हैं, तो सिर्फ पहला टेस्ट चलता है।
हम ऐसा इसलिए करते हैं ताकि आप इस वर्कफ्लो का पालन करें:
- कोई भी नया कोड जोड़ने से पहले टेस्ट सूट चलाइए: आपको एक फेल होता टेस्ट दिखना चाहिए।
- टेस्ट पास कराने के लिए उतना ही कोड जोड़िए, जितना ज़रूरी है।
- टेस्ट सूट चलाइए।
- अगर टेस्ट अब भी फेल होता है, तो चरण 2 दोहराइए।
- टेस्ट पास हो जाने के बाद अपने कोड को अपनी इच्छा के अनुसार रीफैक्टर कीजिए, यह ध्यान रखते हुए कि सभी सक्रिय टेस्ट अब भी पास होते रहें।
रीफैक्टरिंग में ये चीज़ें शामिल हो सकती हैं:
- दोहराया गया कोड हटाना,
- लंबे फंक्शनों को छोटे-छोटे फंक्शनों में बाँटना,
- कमेंट जोड़ना, इत्यादि।
- अगले टेस्ट को "unskip" कीजिए और चरण 1 से दोहराइए।
इन चरणों को तब तक दोहराइए, जब तक सारे टेस्ट unskip न हो जाएँ।
जब सारे टेस्ट पास हो जाएँ, तो बधाई हो, आपने अभ्यास हल कर लिया!
टेस्ट "unskip" (या सक्रिय) कैसे होते हैं, यह ट्रैक पर निर्भर करता है।
कुछ ट्रैक में यह किसी एनोटेशन को कमेंट करना या हटाना हो सकता है।
कुछ ट्रैक में यह किसी एट्रिब्यूट को true से false करना हो सकता है।
अपने ट्रैक का डॉक्यूमेंटेशन ध्यान से पढ़ने के लिए समय निकालिए; इसमें ये बारीकियाँ समझाई गई हैं।
जिन ट्रैक में टेस्ट skip नहीं किए जाते, वहाँ यह वर्कफ्लो अपनाना उतना ही आसान हो सकता है जितना कि टेस्टों को कमेंट कर देना और फिर एक-एक करके उनका कमेंट हटाना।
टेस्ट-ड्रिवन डेवलपमेंट के पीछे का तर्क
भले ही यह "गाड़ी को घोड़े के आगे जोतने" जैसा लगे, पर इम्प्लीमेंटेशन कोड लिखने से पहले यूनिट टेस्ट लिखने के कई अच्छे कारण हैं।
-
डिज़ाइन।
यह आपको सीधे यह सोचने में लगने के बजाय कि कोड कैसे लिखेंगे, पहले अपने प्रोग्राम के इंटरफेस के बारे में सोचने पर मजबूर करता है (यानी यह दुनिया के सामने अपनी कार्यक्षमता कैसे पेश करता है)।
अच्छी तरह डिज़ाइन किया गया (और टेस्ट करने लायक!) इंटरफेस होना अक्सर कुशल इम्प्लीमेंटेशन होने से ज़्यादा ज़रूरी होता है।
-
अनुशासन।
टेस्ट लिखना अक्सर एक बोझ या बाद में सोचने वाली चीज़ माना जाता है; लेकिन टेस्ट पहले लिखने से यह तय हो जाता है कि दिन के अंत में आपने अपने कोड की ज़्यादातर या पूरी कार्यक्षमता कवर करने लायक यूनिट टेस्ट लिख ही लिए होंगे (बजाय इसके कि यह काम कभी हो ही न पाए)।
-
कम मेहनत।
अगर आप यह छोटा चक्र लगातार अपनाएँ: पहले एक टेस्ट लिखिए, फिर उस टेस्ट को पास कराने वाला कोड लिखिए, फिर अगला टेस्ट लिखिए, तो आपका कोड स्वाभाविक रूप से बढ़ता जाता है।
इससे अक्सर (हमेशा नहीं) कम मेहनत बर्बाद होती है; आप वह सारा कोड लिखते हैं जो चाहिए, और वह कोई कोड नहीं लिखते जो नहीं चाहिए।
आगे पढ़ने के लिए
