परिचय

टेस्ट-संचालित विकास अच्छी तरह से परीक्षण और रिफैक्टेबल कोड सुनिश्चित करने के लिए एक प्रभावी तरीका है। मूल विचार यह है कि आप परीक्षण लिखकर विकास शुरू करें। ये परीक्षण स्पष्ट रूप से अपेक्षाओं का दस्तावेजीकरण करते हैं और सफल कार्यान्वयन के लिए रूब्रिक बनाते हैं। जब ठीक से किया जाता है, तो आप किसी भी कोड को लिखने से पहले किसी फ़ंक्शन के अपेक्षित इनपुट/आउटपुट को स्पष्ट रूप से परिभाषित कर सकते हैं। इसके कुछ तात्कालिक लाभ हैं:

• आप अपने कोड के साथ इंटरैक्ट करने के लिए इंटरफ़ेस पर सावधानीपूर्वक विचार करें और इसे परीक्षण योग्य बनाने के लिए डिज़ाइन करें
• जब आप कोड लिखना शुरू करते हैं, तो परिणाम की भविष्यवाणी करने के लिए मैन्युअल परीक्षण या निष्पादन तर्क के माध्यम से कदम उठाने से आपका प्रवाह बाधित नहीं होता है। इसके बजाय, आप बस परीक्षण चलाएं
• परीक्षा पास करना एक ऐसा लक्ष्य बन जाता है जिसे हासिल करना संतोषजनक होता है। प्रक्रिया को अच्छी तरह से परिभाषित और प्राप्त करने योग्य मील के पत्थर की श्रृंखला में विभाजित करने से काम अधिक मनोरंजक हो जाता है
• कार्यान्वयन के बाद आलस्य और अति-आत्मविश्वास से बचें जो आपको अपने कोड का परीक्षण करने से रोक सकता है

अब जब आप लाभों के बारे में आश्वस्त हो गए हैं, तो आप इन चरणों का पालन करके परीक्षण-संचालित विकास (टीडीडी) शुरू कर सकते हैं:

1. परीक्षण लिखें या संशोधित करें
2. जांचें कि क्या परीक्षण विफल रहता है
3. परीक्षण पास करने के लिए न्यूनतम मात्रा में कोड लिखें

इन चरणों का पालन एक चक्र में किया जाता है इसलिए आप वर्तमान कार्यान्वयन को चुनौती देने के लिए हमेशा अधिक परीक्षण जोड़ते रहते हैं।

अंतिम चरण, जो न्यूनतम मात्रा में कोड लिखने को निर्दिष्ट करता है, जहां कठोरता से पालन करने पर चीजें कठिन हो सकती हैं। यह समझना महत्वपूर्ण है कि यह नियम क्यों मौजूद है, इससे पहले कि आप यह निर्धारित कर सकें कि इससे भटकना कब उचित है।

सरल उदाहरण

आपको Add(x, y int) int फ़ंक्शन को लागू करने का काम सौंपा गया है। इससे पहले कि आप कार्यान्वयन पर जाएं और बस xy वापस लौटें, सबसे सरल परीक्षण लिखें: 1 1 == 2. फिर, सबसे सरल कार्यान्वयन क्या है जो परीक्षण पास करेगा? यह अभी वापसी 2 है। अब आपके परीक्षण पास हो गए हैं!

इस बिंदु पर, आपको एहसास होता है कि आपको और अधिक परीक्षणों की आवश्यकता है, इसलिए आप गति बढ़ाते हैं और कुछ और जोड़ते हैं:

• 1 2 == 3
• 100 5 == 105

अब आपके परीक्षण विफल हो गए हैं, इसलिए आपको कार्यान्वयन को ठीक करने की आवश्यकता है। इस बार आप केवल 3 या 105 नहीं लौटा सकते, इसलिए आपको एक ऐसा समाधान ढूंढना होगा जो सभी परीक्षणों के लिए काम करे। इससे कार्यान्वयन होता है: रिटर्न x y.

हालांकि यह मामूली उदाहरण में अत्यधिक थकाऊ लगता है, इस पद्धति का कड़ाई से पालन करने से आपको केवल अपने कार्यान्वयन पर भरोसा करने के बजाय कई परीक्षण लिखने पड़े। बेशक, xy को वापस करने का आपका प्रारंभिक विचार काम कर गया होगा, लेकिन मुद्दा यह है कि कोड की अपनी समझ के बजाय परीक्षणों पर भरोसा करने के लिए खुद को फिर से प्रशिक्षित करें। वास्तविक दुनिया में, आप कोड के इस टुकड़े पर काम करने वाले अकेले नहीं हैं और अनिवार्य रूप से कार्यान्वयन विवरण भूल जाएंगे। यह प्रक्रिया आपको अधिक परीक्षण लिखने और सरल कार्यान्वयन को तोड़ने के अधिक तरीकों के बारे में सोचने के लिए मजबूर करती है।

आखिरकार, आप अनुभव प्राप्त करेंगे और आपके सामने आने वाले विभिन्न परिदृश्यों में काम करने वाला संतुलन बनाना सीखेंगे। आप सुविधाओं के पूर्ण-गति कार्यान्वयन पर वापस लौटेंगे और पाएंगे कि आपके पास कम बग हैं और अधिक रखरखाव योग्य कोड लिखेंगे।

HTTP API के लिए चरण दर चरण TDD

आइए HTTP REST API के लिए TDD का उपयोग करके एक अधिक जटिल उदाहरण देखें। यह चरण-दर-चरण मार्गदर्शिका मेरे गो फ्रेमवर्क, बेबीएपी का उपयोग करती है, लेकिन अवधारणाओं को कहीं भी लागू किया जा सकता है।

बेबीएपीआई गो स्ट्रक्चर्स के आसपास एक पूर्ण सीआरयूडी एपीआई बनाने के लिए जेनेरिक का उपयोग करता है, जिससे पूर्ण आरईएसटी एपीआई और क्लाइंट सीएलआई बनाना बहुत आसान हो जाता है। इसके अलावा, बेबीटेस्ट पैकेज एंड-टू-एंड एपीआई टेबल टेस्ट बनाने के लिए कुछ टूल प्रदान करता है। एपीआई-स्तर पर टीडीडी का उपयोग करने से एक नए एपीआई या फीचर की HTTP और स्टोरेज परतों का एक साथ पूरी तरह से परीक्षण करने की अनुमति मिलती है।

अस्वीकरण: चूंकि बेबीएपी अधिकांश कार्यान्वयन को संभालता है और इसका उपयोग परीक्षण बॉयलरप्लेट उत्पन्न करने के लिए भी किया जाता है, हम तकनीकी रूप से टीडीडी से शुरुआत नहीं कर रहे हैं। हालाँकि, हम देखेंगे कि हमारे एपीआई में PATCH अनुरोधों के लिए समर्थन जोड़ते समय यह कितना फायदेमंद है।

1. एक नया गो प्रोजेक्ट बनाएं
   

2. babyapi के सरल उदाहरण का उपयोग करके प्रारंभिक main.go बनाएं
   

3. टेस्ट बॉयलरप्लेट बनाने के लिए सीएलआई का उपयोग करें
   

4. अपेक्षित JSON के साथ प्लेसहोल्डर भरकर प्रत्येक परीक्षण को कार्यान्वित करें
   

5. परीक्षण चलाएं और देखें कि वे उत्तीर्ण होते हैं!

6. चूंकि PUT निष्क्रिय है, इसलिए इसमें सभी क्षेत्रों को शामिल करना आवश्यक है। इससे बचने के लिए, हम PATCH अनुरोधों के साथ पूर्ण टॉगल के लिए समर्थन जोड़ना चाहते हैं। हम इस सुविधा के दिखने की अपेक्षा के लिए एक सरल परीक्षण जोड़कर शुरुआत करते हैं
   

7. यह परीक्षण विफल हो गया क्योंकि बेबीएपी डिफ़ॉल्ट रूप से PATCH का समर्थन नहीं करता है। हम TODO संरचना के लिए पैच लागू करके इसे ठीक कर सकते हैं। चूंकि हमने अपनी सुविधा को दो परीक्षणों के साथ परिभाषित किया है, हमारा सबसे सरल कार्यान्वयन केवल पूर्ण = सत्य सेट करना नहीं है और हमें अनुरोध से मूल्य का उपयोग करना होगा
   

8. अब हम TODO की पूर्ण स्थिति को बदल सकते हैं, लेकिन हम अभी भी अन्य फ़ील्ड को संशोधित करने के लिए PATCH का उपयोग नहीं कर सकते हैं जैसा कि परीक्षणों के इस नए सेट से पता चलता है
   

9. शेष फ़ील्ड सेट करने के लिए पैच अपडेट करें
   

10. हमारे परीक्षण अभी भी विफल हैं क्योंकि हम हमेशा अनुरोध फ़ील्ड के साथ TODO को अपडेट करते हैं, भले ही वे खाली हों। खाली मानों की जांच के लिए कार्यान्वयन को अद्यतन करके इसे ठीक करें
    

11. नया अपडेटविथपैच परीक्षण पास हो जाता है, लेकिन हमारे पिछले परीक्षण विफल हो जाते हैं। चूंकि हमने पूर्ण को *बूल में बदल दिया है, खाली मान के साथ बनाए गए TODO शून्य के रूप में दिखाई देंगे
    

12. TODO के लिए रेंडर लागू करें ताकि हम शून्य को गलत मान सकें
    

परीक्षण-संचालित विकास के साथ PATCH सुविधा को लागू करने से परीक्षणों का एक मजबूत सेट और एक अच्छी तरह से कार्यान्वित सुविधा प्राप्त हुई। चूंकि हमने परीक्षणों में PATCH अनुरोध के अपेक्षित इनपुट और आउटपुट को परिभाषित करके शुरुआत की थी, इसलिए अनुरोध में खाली मानों की जांच न करने के कारण होने वाली समस्याओं को देखना आसान था। साथ ही, हमारे पहले से मौजूद परीक्षण पूर्ण के प्रकार को *बूल में बदलते समय परिवर्तनों को तोड़ने से बचाने में सक्षम थे।

निष्कर्ष

पूरी तरह से परीक्षण और सही कोड बनाने के लिए परीक्षण-संचालित विकास एक प्रभावी दृष्टिकोण है। परीक्षणों को ध्यान में रखकर शुरुआत करके, हम यह सुनिश्चित कर सकते हैं कि कोड का प्रत्येक भाग परीक्षण को बाद में सोचने के बजाय परीक्षण योग्य बनाने के लिए डिज़ाइन किया गया है।

यदि आप टीडीडी को अपनाने में झिझक रहे हैं, तो आरंभ करने के लिए यहां कुछ उपाय दिए गए हैं:

• इसे सरल परिदृश्यों में आज़माएं जहां फ़ंक्शन का इनपुट/आउटपुट स्पष्ट है और कार्यान्वयन अत्यधिक जटिल नहीं है। आप सामने आने वाले विभिन्न प्रकार के इनपुट/आउटपुट के लिए एक मजबूत तालिका परीक्षण लिख सकते हैं। विभिन्न परिदृश्यों का स्पष्ट दृश्य होने से कार्यान्वयन सरल हो सकता है
• यदि आप एक नया बग ठीक कर रहे हैं, तो आपने पहले ही अपने परीक्षण में एक अंतर पहचान लिया है। एक परीक्षण लिखकर शुरुआत करें जिससे सबसे पहले इस बग की पहचान हो सके। फिर, किसी भी मौजूदा परीक्षण को तोड़े बिना इस परीक्षा को पास करें।
• बेबीएपी उदाहरण के समान, आप उच्च-स्तरीय एपीआई परीक्षणों के लिए टीडीडी का उपयोग कर सकते हैं। एक बार जब आपके पास अपेक्षित अनुरोध/प्रतिक्रिया की परिभाषा हो, तो आप कार्यान्वयन के अधिक विवरण-उन्मुख भागों के लिए अपने सामान्य विकास प्रवाह को फिर से शुरू कर सकते हैं

भले ही टीडीडी आपके कोड लिखने के तरीके के लिए उपयुक्त नहीं है, फिर भी यह आपके लिए एक शक्तिशाली उपकरण है। मैं आपको इसे आज़माने के लिए कम से कम कुछ समय देने और यह देखने के लिए प्रोत्साहित करता हूं कि यह आपकी विकास प्रक्रिया को कैसे प्रभावित करता है।