एजाइल सॉफ्टवेयर विकास के लिए टेस्ट-ड्राइव विकास दृष्टिकोण

अब, लोग अक्सर एजाइल विकास के बारे में बात करते हैं।

एजाइल विकास क्या है?

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

हालांकि, TDD एजाइल विकास विधियों के कई समान संस्करण हैं, जैसे TDD: BDD, DDD और ATDD। मैं TDD के विस्तार से परिचय देने से पहले इन विधियों का संक्षिप्त परिचय देता हूं:

TDD: टेस्ट-ड्राइव विकास

टेस्ट ड्राइव विकास (TDD) एक सॉफ्टवेयर विकास प्रक्रिया है, जो सॉफ्टवेयर के पूर्ण विकास से पहले सॉफ्टवेयर आवश्यकताओं को परीक्षण मामलों में बदलने पर निर्भर होती है, और सभी परीक्षण मामलों के लिए सॉफ्टवेयर के बार-बार परीक्षण द्वारा सभी सॉफ्टवेयर विकास का अनुसरण करती है। यह सॉफ्टवेयर के पहले विकास करने और फिर परीक्षण मामले बनाने के विपरीत है। कुछ लोकप्रिय मॉडल TDD का बहुत अच्छा समर्थन करते हैं, जैसे MVC और MVP.

BDD: व्यवहार ड्राइव विकास (व्यवहार ड्राइव विकास)

व्यवहार ड्राइव विकास (BDD) एक एजाइल सॉफ्टवेयर विकास प्रक्रिया भी है। यह सॉफ्टवेयर परियोजनाओं में डेवलपर्स, गुणवत्ता आयोग परीक्षकों और ग्राहक प्रतिनिधियों के बीच सहयोग को प्रोत्साहित करता है। यह टीमों को चर्चा और वास्तविक उदाहरणों का उपयोग करके यह समझने के लिए प्रोत्साहित करता है कि एप्लिकेशन कैसे काम करना चाहिए। यह टेस्ट ड्राइव विकास (TDD) से उत्पन्न हुआ है।

ATDD: स्वीकृति परीक्षण ड्राइव विकास

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

DDD: डोमेन ड्राइव डिज़ाइन

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

TDD कार्यान्वयन योजना

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

विकास सिद्धांत

पहले परीक्षण कोड लिखें, और फिर फंक्शन के लिए कोड लिखें।

1. आवश्यकता दस्तावेज़ के अनुसार परीक्षण कोड लिखें, फंक्शन को लागू करने के लिए नहीं;
2. एक बार में बहुत खाने की इच्छा नहीं है। बड़े फंक्शनल ब्लॉक्स के परीक्षण करते समय, आपको पहले उन्हें छोटे फंक्शनल ब्लॉक्स में विभाजित करना चाहिए ताकि परीक्षण किया जा सके;
3. याद रखें कि फंक्शन को पूरा करने के लिए कोड न लिखें, सबसे सरल संभव कोड का उपयोग करके फंक्शन को लागू करें;
4. यदि आवश्यकताओं को परीक्षण किया जा सकता है, तो परीक्षण कोड लिखें, और उन्हें छोड़ दें जो परीक्षण नहीं किए जा सकते हैं या जिन्हें आपको लगता है कि उनका परीक्षण करने की आवश्यकता नहीं है;
5. किसी भी फंक्शन कोड को बदलने/जोड़ने से पहले, आपको पहले यह सोचना होगा कि क्या आप परीक्षण मामलों को बदलना/जोड़ना चाहते हैं;
6. फंक्शन/टेस्ट कोड, अनुचित संरचना, दोहराए गए कोड आदि, टेस्ट पास होने के बाद समय पर रिफैक्टर करें।

TDD विकास प्रक्रिया

1. लक्ष्य टेस्ट स्थिति का विश्लेषण और निर्धारण करें;
2. टेस्ट स्थिति के इनपुट और आउटपुट की पुष्टि करने के लिए एक यूनिट टेस्ट जोड़ें;
3. टेस्ट चलाएं और असफल टेस्ट परिणाम प्राप्त करें;
4. टेस्ट पास करने के लिए सबसे सरल फंक्शन कोड लिखें;
5. टेस्ट को फिर से चलाएं और देखें कि टेस्ट पास हो जाता है;
6. कोड रिफैक्टरिंग करें, जिसमें कार्यात्मक कोड और यूनिट टेस्ट कोड शामिल है;
7. विकास पूरा होने तक उपरोक्त चरणों को दोहराएं।

TDD के लाभ

1. विकासकर्मियों पर भार कम करें. स्पष्ट प्रक्रिया के माध्यम से, हमें एक समय में केवल एक बिंदु पर ध्यान केंद्रित करने दें, और सोचने का भार कम होता है।
2. सुरक्षा जाल. पूर्ण यूनिट टेस्टिंग के माध्यम से उत्पाद कोड के लिए एक सुरक्षा जाल प्रदान करता है, जिससे आवश्यकताओं में बदलाव के लिए आसानी से अनुकूलित करना या कोड डिजाइन में सुधार करना संभव होता है। इसलिए यदि आपके प्रोजेक्ट की आवश्यकताएं स्थिर हैं, एक बार में पूरी हो गई हैं और बाद में कोई बदलाव नहीं है, तो TDD के लाभ कम होते हैं।
3. आवश्यकताओं को पहले से स्पष्ट करें. पहले टेस्ट लिखने से हमें आवश्यकताओं पर विचार करने में मदद मिलती है और आवश्यकताओं के विवरण को पहले से स्पष्ट करने में सहायता मिलती है, बजाय इसके कि कोड के आधे रास्ते पर अस्पष्ट आवश्यकताओं का पता लगाएं।
4. त्वरित प्रतिक्रिया. बहुत से लोग कहते हैं कि TDD के दौरान मेरा कोड आयतन बढ़ जाता है, इसलिए विकास दक्षता कम हो जाती है। हालांकि, यदि आपके पास यूनिट टेस्ट नहीं हैं, तो आपको उन्हें हाथ से टेस्ट करना होगा, आप बहुत समय डेटा तैयार करने, ऐप लॉन्च करने, इंटरफेस संशोधित करने आदि में लगाते हैं, और प्रतिक्रिया धीमी होती है। सटीक रूप से, त्वरित प्रतिक्रिया यूनिट टेस्टिंग का लाभ है।