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

परीक्षण संचालित विकास

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

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

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

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

इस ट्यूटोरियल में, आप के बारे में अधिक जानेंगे-

• TDD टेस्ट कैसे करें
• TDD बनाम। पारंपरिक परीक्षण
• टीडीडी और डेवलपर टीडीडी क्या है
• फुर्तीली मॉडल प्रेरित विकास (AMDD) के माध्यम से TDD स्केलिंग
• टेस्ट ड्रिवेन डेवलपमेंट (TDD) बनाम फुर्तीली मॉडल संचालित विकास (AMDD)
• टीडीडी का उदाहरण
• TDD के लाभ

TDD टेस्ट कैसे करें

निम्नलिखित कदम निर्धारित करते हैं कि TDD टेस्ट कैसे करें,

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

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

1. एक परीक्षण लिखें
2. इसे चलाएं।
3. इसे सही करने के लिए कोड बदलें यानी रिफ्लेक्टर।
4. दोहराने की प्रक्रिया।

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

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

TDD बनाम। पारंपरिक परीक्षण

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

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

टीडीडी और डेवलपर टीडीडी क्या है

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

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

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

फुर्तीली मॉडल प्रेरित विकास (AMDD) के माध्यम से TDD स्केलिंग

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

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

एएमडी का जीवनचक्र।

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

उपरोक्त आंकड़ों में, प्रत्येक बॉक्स एक विकास गतिविधि का प्रतिनिधित्व करता है।

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

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

1. Iteration 0: कल्पना करना

दो मुख्य उप-सक्रियताएं हैं।

1. प्रारंभिक आवश्यकताओं की कल्पना।

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

2. प्रारंभिक स्थापत्य कला में संशोधन।

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

2. Iteration मॉडलिंग:

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

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

3. मॉडल तूफान:

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

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

4. टेस्ट ड्रिवेन डेवलपमेंट (TDD)।

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

5. समीक्षा।

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

टेस्ट ड्रिवेन डेवलपमेंट (TDD) बनाम फुर्तीली मॉडल संचालित विकास (AMDD)

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

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

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

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

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

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

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

हम क्लास टेस्टपासवर्ड () से ऊपर चलेंगे;

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

आउटपुट :

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

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

तो हम नीचे के रूप में Refactor (कोड बदलें):

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

इसलिए हमें बूलियन से पहले "स्थिर" शब्द को सार्वजनिक स्थैतिक बूलियन isValid (स्ट्रिंग पासवर्ड) के रूप में जोड़कर इस पद्धति को बदलना होगा। परीक्षा पास करने के लिए उपरोक्त त्रुटि को दूर करने के लिए क्लास पासवर्डवैलिलेटर () को रिफैक्ट करना।

आउटपुट:

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

TDD के लाभ

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

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

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

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

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

  यद्यपि डेवलपर्स को TDD परीक्षण मामलों को लिखने में अधिक समय बिताना पड़ता है, लेकिन डिबगिंग और नई विशेषताओं को विकसित करने में बहुत कम समय लगता है। आप क्लीनर, कम जटिल कोड लिखेंगे।

सारांश:

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

यह लेख कंचन कुलकर्णी द्वारा योगदान दिया गया है