टेस्ट ड्रिवेन डेवलपमेंट (TDD) क्या है? उदाहरण

परीक्षण संचालित विकास (टीडीडी) क्या है?

परीक्षण संचालित विकास (टीडीडी) यह सॉफ्टवेयर विकास दृष्टिकोण है जिसमें कोड क्या करेगा यह निर्दिष्ट करने और मान्य करने के लिए परीक्षण मामले विकसित किए जाते हैं। सरल शब्दों में, प्रत्येक कार्यक्षमता के लिए परीक्षण मामले बनाए जाते हैं और पहले उनका परीक्षण किया जाता है और यदि परीक्षण विफल हो जाता है तो परीक्षण को पास करने और कोड को सरल और बग-मुक्त बनाने के लिए नया कोड लिखा जाता है।

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

टीडीडी की सरल अवधारणा नया कोड लिखने से पहले (विकास से पहले) असफल परीक्षणों को लिखना और सुधारना है। यह कोड के दोहराव से बचने में मदद करता है क्योंकि हम परीक्षणों को पास करने के लिए एक बार में थोड़ी मात्रा में कोड लिखते हैं। (परीक्षण कुछ और नहीं बल्कि आवश्यकता की शर्तें हैं जिन्हें पूरा करने के लिए हमें उनका परीक्षण करना होता है)।

टेस्ट-ड्रिवेन डेवलपमेंट, एप्लीकेशन के वास्तविक विकास से पहले स्वचालित परीक्षण विकसित करने और चलाने की एक प्रक्रिया है। इसलिए, TDD को कभी-कभी यह भी कहा जाता है प्रथम विकास का परीक्षण करें।

टीडीडी टेस्ट कैसे करें

निम्नलिखित चरण टीडीडी परीक्षण करने का तरीका परिभाषित करते हैं,

1. एक परीक्षण जोड़ें.
2. सभी परीक्षण चलाएं और देखें कि क्या कोई नया परीक्षण विफल होता है।
3. कुछ कोड लिखें।
4. परीक्षण चलाएँ और कोड को पुनःसंयोजित करें।
5. दोहराएँ।

टीडीडी चक्र परिभाषित करता है

1. एक परीक्षण लिखें
2. इसे चलाओ.
3. कोड को सही करने के लिए उसमें परिवर्तन करें अर्थात रिफैक्टर करें।
4. प्रक्रिया दोहराएँ.

टी.डी.डी. के बारे में कुछ स्पष्टीकरण:

• टीडीडी दृष्टिकोण न तो “परीक्षण” के बारे में है और न ही “डिज़ाइन” के बारे में है।
• टीडीडी का अर्थ यह नहीं है कि "कुछ परीक्षण लिखें, फिर एक ऐसी प्रणाली बनाएं जो परीक्षणों में सफल हो जाए।"
• टीडीडी का मतलब "बहुत सारे परीक्षण करना" नहीं है।

टीडीडी बनाम पारंपरिक परीक्षण

परीक्षण संचालित विकास और पारंपरिक परीक्षण के बीच मुख्य अंतर नीचे दिया गया है:

टीडीडी दृष्टिकोण मुख्य रूप से एक विनिर्देशन तकनीक है। यह सुनिश्चित करता है कि आपके स्रोत कोड का पुष्टिकरण स्तर पर पूरी तरह से परीक्षण किया गया है।

• पारंपरिक परीक्षण में, एक सफल परीक्षण में एक या अधिक दोष पाए जाते हैं। यह TDD के समान ही है। जब कोई परीक्षण विफल हो जाता है, तो आप प्रगति कर चुके होते हैं क्योंकि आप जानते हैं कि आपको समस्या को हल करने की आवश्यकता है।
• TDD यह सुनिश्चित करता है कि आपका सिस्टम वास्तव में इसके लिए निर्धारित आवश्यकताओं को पूरा करता है। यह आपके सिस्टम के बारे में आपका आत्मविश्वास बढ़ाने में मदद करता है।
• टीडीडी में ज़्यादा ध्यान उत्पादन कोड पर होता है जो यह सत्यापित करता है कि परीक्षण ठीक से काम करेगा या नहीं। पारंपरिक परीक्षण में, ज़्यादा ध्यान परीक्षण मामले के डिज़ाइन पर होता है। क्या परीक्षण आवश्यकताओं को पूरा करने के लिए एप्लिकेशन के उचित/अनुचित निष्पादन को दिखाएगा।
• TDD में, आप 100% कवरेज परीक्षण प्राप्त करते हैं। पारंपरिक परीक्षण के विपरीत, कोड की हर एक पंक्ति का परीक्षण किया जाता है।
• पारंपरिक परीक्षण और टीडीडी दोनों के संयोजन से सिस्टम की पूर्णता के बजाय सिस्टम के परीक्षण को महत्व मिलता है।
• In एजाइल मॉडलिंग (AM)आपको “उद्देश्य के साथ परीक्षण करना चाहिए”। आपको पता होना चाहिए कि आप किसी चीज़ का परीक्षण क्यों कर रहे हैं और उसे किस स्तर पर परीक्षण करने की आवश्यकता है।

स्वीकृति TDD और डेवलपर TDD क्या है?

टीडीडी के दो स्तर हैं

1. स्वीकृति टीडीडी (ATDD): ATDD के साथ आप एक एकल स्वीकृति परीक्षण लिखते हैं। यह परीक्षण विनिर्देश की आवश्यकता को पूरा करता है या सिस्टम के व्यवहार को संतुष्ट करता है। उसके बाद उस स्वीकृति परीक्षण को पूरा करने के लिए पर्याप्त उत्पादन/कार्यक्षमता कोड लिखें। स्वीकृति परीक्षण सिस्टम के समग्र व्यवहार पर केंद्रित है। ATDD को इस नाम से भी जाना जाता है व्यवहार प्रेरित विकास (बीडीडी).
2. डेवलपर टीडीडी: डेवलपर TDD के साथ आप एकल डेवलपर परीक्षण यानी यूनिट टेस्ट लिखते हैं और फिर उस परीक्षण को पूरा करने के लिए पर्याप्त उत्पादन कोड लिखते हैं। यूनिट टेस्ट सिस्टम की हर छोटी कार्यक्षमता पर ध्यान केंद्रित करता है। डेवलपर TDD को बस इस प्रकार कहा जाता है टीडीडी।ATDD और TDD का मुख्य लक्ष्य आपके समाधान के लिए समय पर (JIT) विस्तृत, निष्पादन योग्य आवश्यकताओं को निर्दिष्ट करना है। JIT का मतलब है केवल उन आवश्यकताओं को ध्यान में रखना जो सिस्टम में आवश्यक हैं। इसलिए दक्षता बढ़ाएँ।

एजाइल मॉडल ड्रिवेन डेवलपमेंट (AMDD) के माध्यम से TDD का स्केलिंग

TDD विस्तृत विनिर्देशन और सत्यापन में बहुत अच्छा है। यह समग्र डिजाइन, सिस्टम के उपयोग या UI जैसे बड़े मुद्दों पर विचार करने में विफल रहता है। AMDD एजाइल स्केलिंग मुद्दों को संबोधित करता है जो TDD नहीं करता है।

इस प्रकार AMDD का उपयोग बड़े मुद्दों के लिए किया जाता है।

AMDD का जीवनचक्र

मॉडल-संचालित विकास (MDD) में, स्रोत कोड लिखे जाने से पहले व्यापक मॉडल बनाए जाते हैं। जिसके परिणामस्वरूप एक चुस्त दृष्टिकोण होता है?

उपरोक्त चित्र में, प्रत्येक बॉक्स एक विकास गतिविधि को दर्शाता है।

एनविज़निंग, प्रोजेक्ट के पहले सप्ताह के दौरान किए जाने वाले परीक्षणों की भविष्यवाणी/कल्पना करने की TDD प्रक्रिया में से एक है। एनविज़निंग का मुख्य लक्ष्य सिस्टम के दायरे और सिस्टम की वास्तुकला की पहचान करना है। सफल एनविज़निंग के लिए उच्च-स्तरीय आवश्यकताओं और वास्तुकला मॉडलिंग की जाती है।

यह वह प्रक्रिया है जिसमें सॉफ्टवेयर/सिस्टम का विस्तृत विवरण नहीं दिया जाता, बल्कि सॉफ्टवेयर/सिस्टम की आवश्यकताओं का पता लगाया जाता है, जो परियोजना की समग्र रणनीति को परिभाषित करता है।

पुनरावृति 0: कल्पना करना

इसमें दो मुख्य उप-सक्रियण हैं।

1. प्रारंभिक आवश्यकताओं की कल्पना.सिस्टम की उच्च-स्तरीय आवश्यकताओं और दायरे की पहचान करने में कई दिन लग सकते हैं। मुख्य ध्यान उपयोग मॉडल, प्रारंभिक डोमेन मॉडल और उपयोगकर्ता इंटरफ़ेस मॉडल (UI) का पता लगाने पर है।
2. प्रारंभिक Archiसंरचनात्मक कल्पना. सिस्टम की वास्तुकला की पहचान करने में भी कई दिन लगते हैं। यह परियोजना के लिए तकनीकी दिशाएँ निर्धारित करने की अनुमति देता है। मुख्य ध्यान प्रौद्योगिकी आरेख, उपयोगकर्ता इंटरफ़ेस (UI) प्रवाह, डोमेन मॉडल और परिवर्तन मामलों का पता लगाने पर है।

पुनरावृत्ति मॉडलिंग

यहां टीम को प्रत्येक पुनरावृत्ति के लिए किए जाने वाले कार्य की योजना बनानी होगी।

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

मॉडल स्टॉर्मिंग

इसे जस्ट इन टाइम मॉडलिंग के नाम से भी जाना जाता है।

• यहां मॉडलिंग सत्र में 2/3 सदस्यों की टीम शामिल होती है जो कागज या व्हाइटबोर्ड पर मुद्दों पर चर्चा करती है।
• एक टीम सदस्य दूसरे को उनके साथ मॉडलिंग करने के लिए कहेगा। इस मॉडलिंग सत्र में लगभग 5 से 10 मिनट लगेंगे। जहाँ टीम के सदस्य व्हाइटबोर्ड/पेपर साझा करने के लिए एक साथ इकट्ठा होते हैं।
• वे तब तक समस्याओं का पता लगाते हैं जब तक कि उन्हें समस्या का मुख्य कारण नहीं मिल जाता। समय रहते, अगर टीम का कोई सदस्य उस समस्या की पहचान कर लेता है जिसे वह हल करना चाहता है, तो वह तुरंत टीम के अन्य सदस्यों की मदद लेगा।
• इसके बाद समूह के अन्य सदस्य समस्या का पता लगाते हैं और फिर सभी पहले की तरह आगे बढ़ते हैं। इसे स्टैंड-अप मॉडलिंग या ग्राहक QA सत्र भी कहा जाता है।

परीक्षण संचालित विकास (टीडीडी)

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

समीक्षाएँ

• यह वैकल्पिक है। इसमें कोड निरीक्षण और मॉडल समीक्षा शामिल है।
• यह प्रत्येक पुनरावृत्ति के लिए या संपूर्ण परियोजना के लिए किया जा सकता है।
• यह परियोजना के लिए फीडबैक देने का एक अच्छा विकल्प है।

टेस्ट ड्रिवेन डेवलपमेंट (TDD) बनाम एजाइल मॉडल ड्रिवेन डेवलपमेंट (AMDD)

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

टीडीडी फ्रेमवर्क

यहां सर्वश्रेष्ठ परीक्षण संचालित विकास (TDD) फ्रेमवर्क की सूची दी गई है

1. JUnit
2. TestNG
3. csUnit और NUnit
4. आरएसपीसी

अब, आइए उदाहरण द्वारा टेस्ट संचालित विकास सीखें।

टी.डी.डी. का उदाहरण

यहाँ इस टेस्ट ड्रिवेन डेवलपमेंट उदाहरण में, हम एक क्लास पासवर्ड परिभाषित करेंगे। इस क्लास के लिए, हम निम्नलिखित शर्तों को पूरा करने का प्रयास करेंगे।

पासवर्ड स्वीकृति हेतु एक शर्त:

• पासवर्ड 5 से 10 अक्षरों के बीच होना चाहिए।

इस TDD उदाहरण में सबसे पहले, हम वह कोड लिखते हैं जो उपरोक्त सभी आवश्यकताओं को पूरा करता है।

परिदृश्य 1: परीक्षण चलाने के लिए, हम क्लास पासवर्ड वैलिडेटर () बनाते हैं;

हम ऊपर दिए गए क्लास TestPassword () चलाएंगे;

आउटपुट PASSED है जैसा कि नीचे दिखाया गया है;

उत्पादन:

परिदृश्य 2: यहाँ हम देख सकते हैं कि TestPasswordLength () विधि में क्लास PasswordValidator का इंस्टेंस बनाने की कोई आवश्यकता नहीं है। इंस्टेंस का अर्थ है एक बनाना वस्तु उस वर्ग के सदस्यों (चर/विधियों) को संदर्भित करने के लिए वर्ग का।

हम कोड से क्लास पासवर्ड वैलिडेटर pv = new पासवर्ड वैलिडेटर () हटा देंगे। हम कॉल कर सकते हैं वैध है () विधि द्वारा सीधे पासवर्ड वैलिडेटर. IsValid (“Abc123”). (नीचे चित्र देखें)

इसलिए हम नीचे दिए अनुसार रिफैक्टर (कोड बदलते हैं):

परिदृश्य 3: रीफैक्टरिंग के बाद आउटपुट विफल स्थिति दिखाता है (नीचे छवि देखें) ऐसा इसलिए है क्योंकि हमने इंस्टेंस को हटा दिया है। इसलिए गैर-स्थैतिक विधि का कोई संदर्भ नहीं है वैध है ().

इसलिए हमें बूलियन से पहले “स्टेटिक” शब्द जोड़कर इस विधि को बदलने की आवश्यकता है, जैसे कि public static boolean isValid (String password)। परीक्षण पास करने के लिए उपरोक्त त्रुटि को हटाने के लिए क्लास पासवर्डवैलिडेटर () को रिफैक्टर करना।

आउटपुट:

PassValidator () क्लास में परिवर्तन करने के बाद यदि हम परीक्षण चलाते हैं तो आउटपुट PASSED होगा जैसा कि नीचे दिखाया गया है।

टीडीडी के लाभ

सॉफ्टवेयर इंजीनियरिंग में टेस्ट संचालित विकास के मुख्य लाभ निम्नलिखित हैं:

प्रारंभिक बग अधिसूचना.

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

बेहतर डिज़ाइन, स्वच्छ और अधिक विस्तार योग्य कोड।

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

रिफैक्टर का आत्मविश्वास

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

टीमवर्क के लिए अच्छा

• किसी भी टीम सदस्य की अनुपस्थिति में, अन्य टीम सदस्य आसानी से कोड को समझ सकते हैं और उस पर काम कर सकते हैं। इससे ज्ञान साझा करने में भी मदद मिलती है, जिससे टीम समग्र रूप से अधिक प्रभावी बनती है।

डेवलपर्स के लिए अच्छा

• हालाँकि डेवलपर्स को TDD टेस्ट केस लिखने में ज़्यादा समय लगाना पड़ता है, लेकिन डिबगिंग और नए फ़ीचर विकसित करने में बहुत कम समय लगता है। आप ज़्यादा साफ़, कम जटिल कोड लिखेंगे।

सारांश

• टीडीडी का तात्पर्य परीक्षण-संचालित विकास से है।
• टीडीडी का अर्थ: यह पहले से डिज़ाइन किए गए परीक्षण को पास करने के लिए कोड को संशोधित करने की एक प्रक्रिया है।
• इसमें परीक्षण केस डिजाइन की अपेक्षा उत्पादन कोड पर अधिक जोर दिया गया।
• परीक्षण-संचालित विकास, पहले से डिज़ाइन किए गए परीक्षण को पास करने के लिए कोड को संशोधित करने की एक प्रक्रिया है।
• In सॉफ्टवेयर इंजीनियरिंग, इसे कभी-कभी इस नाम से भी जाना जाता है “पहले विकास का परीक्षण करें।”
• टीडीडी परीक्षण में कोड को रिफैक्टर करना शामिल है, अर्थात कोड के व्यवहार को प्रभावित किए बिना मौजूदा कोड में कुछ मात्रा में कोड को बदलना/जोड़ना।
• टीडीडी प्रोग्रामिंग का उपयोग करने पर कोड स्पष्ट और समझने में सरल हो जाता है।