परीक्षण-संचालित विकास (TDD) और विकास-संचालित परीक्षण (DDT) के बारे में सब क्यों चुस्त है?

74

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

यह मैं कैसे TDD की कल्पना करता हूं और यह मुझे भ्रमित क्यों करता है। अगर मुझे टीडीडी ठेकेदार के रूप में एक घर बनाना था।

मुझे अपने सभी चश्मे (कहानियाँ) दे दो।
चश्मे पर स्वीकृति प्राप्त करें।
निरीक्षण में सभी चश्मा तोड़ दें मुझे लगता है कि मुझे (भविष्य में देखें) की आवश्यकता होगी।
उन बिंदुओं को देखने के लिए एक निरीक्षक को बुलाएं और मुझे बताएं कि अभी मैं निरीक्षण में असफल रहा हूं (जी धन्यवाद)।
घर बनाना शुरू करें।
प्रतिदिन इंस्पेक्टर को वापस बुला लें (2/100 पास)।
ओह शूट, मेरी समझ के साथ एक मुद्दा था और अब मुझे 9 और निरीक्षण जोड़ने और उनमें से 27 को बदलने की आवश्यकता है।
कॉल इंस्पेक्टर पासिंग 1/109।
लानत है। इंस्पेक्टर ऐसा क्यों नहीं करता ... ओह, मैंने उस विधि का नाम अपडेट कर दिया है ...
कुछ और बनाएँ।
UGGGGHHHH अधिक परिवर्तन मुझे लानत निरीक्षक को अद्यतन करने दें। ओह, मैं असफल नहीं हो रहा हूं ** टी।
क्या मैंने अभी तक किया है?

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

जो अधिक उचित लगता है वह है डीडीटी या विकास-संचालित परीक्षण, जो एक ऐसी चीज है जिसे समुदाय के सभी लोग भूल गए हैं लेकिन ऐसा लगता है।

मेरी समझ से एक घर के लिए डीडीटी ऐसा लगेगा:

मुझे अपने सभी चश्मे (कहानियाँ) दे दो।
ऐनक पर स्वीकृति प्राप्त करें और उन्हें तोड़ दें।
एक इकाई (नींव) शुरू करो।
कुछ पेचीदा तर्क के नोट्स (टिप्पणियां) लें।
अगली इकाई शुरू करने से पहले अंत में निरीक्षण (एक परीक्षण बनाएं) करें।
मिले किसी भी मुद्दे को ठीक करें और फिर से निरीक्षण करें।
इस इकाई को अगले कदम पर मंजूरी दे दी।

अगर हम सभी ईमानदार हो रहे हैं तो क्या यह ध्वनि अधिक मानवीय और डेवलपर और व्यवसाय पर केंद्रित नहीं है? ऐसा लगता है कि परिवर्तन तेजी से किए जा सकते हैं और ओवरहेड के बिना टीडीडी बनाने लगता है।

agile tdd development-methodologies

— nerdlyist
स्रोत

60

मेरे लिए चकाचौंध दूर करने वाला विचार यह है कि कोड को लिखने से पहले आपके पास 100+ असफल परीक्षण हो सकते हैं जो उन्हें पारित करना शुरू कर देते हैं। जैसा कि @Telastyn कहते हैं, एक समय में कुछ असफल परीक्षणों से अधिक नहीं होना चाहिए। "टेस्ट तो कोड तो टेस्ट" लिख मतलब यह नहीं है सब किसी भी कोड लिखने से पहले एप्लिकेशन के परीक्षण की।

— एरिक किंग

33

मेटाफ़ोर्स एक एंटीपैटर्न हैं! लोग यह समझाने में अधिक समय व्यतीत करेंगे कि आपका रूपक आपकी वास्तविक चिंता का समाधान करने के बजाए विषय के अनुकूल क्यों नहीं है। इस मामले में आपकी वास्तविक चिंता यह प्रतीत होती है कि आपको लगता है कि आपको सभी परीक्षणों को आगे लिखना होगा ।

— जैक्सबी

21

यहां एक साइड-नोट के रूप में, TDD का उपयोग आमतौर पर फुर्तीली परियोजनाओं में किया जाता है, लेकिन मुझे लगता है कि फुर्तीली परियोजना प्रबंधन और फुर्तीली विकास प्रथाओं के बीच अंतर करना महत्वपूर्ण है। दोनों के बीच बहुत मजबूत रिश्ता नहीं है। आप परियोजना पद्धति और इसके विपरीत की परवाह किए बिना अधिकांश चुस्त विकास प्रथाओं का उपयोग कर सकते हैं। यह अक्सर भूल जाता है कि चुस्त है, यह वास्तव में, अपने दृष्टिकोण को अपनाने के बारे में है जैसा कि सबसे अच्छा परिणाम प्राप्त करने के लिए आवश्यक है और उन चीजों की एक निर्धारित सूची के बारे में नहीं जो आपको करना चाहिए। दूसरे शब्दों में, एजाइल! = स्क्रम + टीडीडी।

— जिमीजैम्स

35

रिकॉर्ड के लिए, घर बनाने के लिए सॉफ्टवेयर विकास की तुलना करना व्यर्थ है। पढ़ाई हो चुकी है। परिणाम सामने हैं। उत्तर स्पष्ट है। आप बस उसी तरह से सॉफ्टवेयर नहीं बनाते हैं जिस तरह से आप घर बनाते हैं। । दो। कर रहे हैं। विभिन्न।

— रिवलॉक

14

फुर्तीली सभी फास्ट फीडबैक लूप्स के बारे में है, टीडीडी सिर्फ एक विशेष प्रकार का फीडबैक लूप है

— jk।

83

टीडीडी दृष्टिकोण के लाभों में से एक का एहसास केवल तब होता है जब आप आकस्मिक डिजाइन भी करते हैं।

इसलिए आपके पहले सादृश्य में, आप 100 परीक्षण नहीं लिखेंगे, क्योंकि ऐसा कोई संभव तरीका नहीं है कि आपको पता चल जाएगा कि आपका सॉफ़्टवेयर कैसा दिखेगा।

आप एक परीक्षण लिखें। आप इसे चलाते हैं। यह विफल रहा। आप अपना टेस्ट पास करने के लिए कोड की सबसे छोटी इकाई लिखते हैं। फिर आप अपना टेस्ट दोबारा चलाते हैं। वो चला गया।

अब ऊपर की प्रक्रिया को दोहराते हुए अगला टेस्ट लिखें।

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

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

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

एक बार जब आप मानसिकता में आ जाते हैं, तो इसमें न रहना और "पुराने जमाने" को कोड करना बहुत मुश्किल होता है।

मैं इसे सीखने के लिए एक अच्छा चुस्त वातावरण में काम करने की सलाह दूंगा, या बेहतर समझने के लिए कुछ अच्छी फुर्तीली किताबें (क्लीन कोड और क्लीन कोडर दोनों बहुत अच्छी हैं)।

— फिल रिले
स्रोत

46

"एमर्जेंट डिज़ाइन" शब्द ऐसा लगता है जैसे आप टेस्ट पास करके किसी सॉफ्टवेयर डिज़ाइन को विकसित कर सकते हैं। आप नहीं कर सकते।

— रॉबर्ट हार्वे

28

@nerdlyist: डिज़ाइन के बारे में मत भूलना, हालाँकि। आपको अभी भी सॉफ़्टवेयर डिज़ाइन करने की आवश्यकता है; अच्छा डिज़ाइन केवल प्राकृतिक रूप से लाल-हरे-रिफ्लेक्टर से नहीं निकलता है। टीडीडी अच्छे डिजाइन को प्रोत्साहित करता है, लेकिन यह इसे नहीं बनाता है।

— रॉबर्ट हार्वे

19

@RobertHarvey, मैं आपके " The Emergent Design" शब्द से पूरी तरह असहमत हूँ, यह आपको ध्वनि देता है जैसे आप टेस्ट पास करके किसी सॉफ़्टवेयर डिज़ाइन को विकसित कर सकते हैं। आप "कथन" नहीं कर सकते । कई अवसरों पर ऐसा करने के बाद, मैं आपको विश्वास दिलाता हूं कि यह किया जा सकता है।

— डेविड अर्नो

12

@DavidArno: क्या आप हाथ में एक आवश्यकता विनिर्देशन के साथ शुरू करते हैं? आप उस विनिर्देश को एक समझदार वास्तुकला में कैसे बदल सकते हैं? क्या आप इसे हर बार परीक्षणों के साथ सुदृढ़ करते हैं, या क्या आपके पास पिछले वास्तु सिद्धांतों को ध्यान में रखते हैं? अंधों में कोई भी ऐसा नहीं करता है; आपके परीक्षणों को लिखने के बारे में कुछ भी जादुई नहीं है, इसके अलावा यह आपको अपने कोड को अधिक परीक्षण योग्य बनाने के लिए मजबूर करता है।

— रॉबर्ट हार्वे

45

@DavidArno मुझे लगता है कि आपकी आपत्ति एक अनुभवी डेवलपर / आर्किटेक्ट के रूप में खुद को पर्याप्त क्रेडिट न देने से उपजी है। क्योंकि आप पहले से ही जानते हैं कि मॉड्यूल एक्स सहज रूप से कैसा दिखता है , आपके परीक्षण आपके विकास को एक अच्छी दिशा में ले जाएंगे। एक अनुभवहीन डेवलपर के पास कुछ नहीं के साथ सहज ज्ञान युक्त धारणा है कि परीक्षण लिखने से पहले एक मॉड्यूल कैसा दिखना चाहिए, एक अच्छी तरह से परीक्षण किया गया, क्रेज़ी मॉड्यूल का निर्माण करेगा।

— svidgen

86

सॉफ्टवेयर एक घर नहीं है। अंतर्ज्ञान अच्छा है, लेकिन यह समझें कि यह हमेशा सही नहीं होता है।

निरीक्षण में सभी चश्मा तोड़ दें मुझे लगता है कि मुझे (भविष्य में देखें) की आवश्यकता होगी।

यह सही नहीं है। TDD में, आप बता रहे हैं कि आप कोड का उपयोग कैसे करना चाहते हैं। चश्मा कहता है "एक घर होना चाहिए, इसमें प्रवेश करने का एक तरीका है।" परीक्षण फिर कहता है "अरे, मैं एक सामने वाला दरवाजा रखना चाहता हूं, एक घुंडी के साथ।" यह अभी तक भविष्य में दरवाजे की चौखट, घुंडी, कीलॉक आदि के क्रियान्वयन से शुरू होता है (या तो तर्क)।

प्रतिदिन इंस्पेक्टर को वापस बुला लें (2/100 पास)।

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

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

ऐसा लगता है कि परिवर्तन तेजी से किए जा सकते हैं और ओवरहेड के बिना टीडीडी बनाने लगता है।

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

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

कॉलेज में मेरे प्रोफेसर टेस्ट के विचार के बाद कोड और फिर टेस्ट के बारे में थे।

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

— Telastyn
स्रोत

18

+1 केवल अंतिम पैराग्राफ के लिए। आपका घर उदाहरण वास्तव में उजागर करता है कि "धार्मिक डीटीडी" कितना मूर्खतापूर्ण हो सकता है।

— रॉबर्ट हार्वे

23

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

— ट्रेवर बॉयड स्मिथ

1

@TrevorBoydSmith आप उस बिंदु पर दस्तावेज नहीं लिखेंगे जो आवश्यकताएं नहीं हैं।

— nddlyist 16

8

क्योंकि TDD कोड के उपयोगकर्ता के परिप्रेक्ष्य में डालता है , [सबसे अच्छी स्थिति में] यह बेहतर इंटरफेस को बढ़ावा देता है। उदाहरण के लिए, जब मैं फोन करता open_doorहूं , तो मुझे इसके लिए एक झंडा नहीं देना चाहिए toilet_flushed; इसलिए मैं अपना परीक्षण इस तरह नहीं लिखता और इसलिए मेरे कोड में ये "खुरदुरे किनारे" नहीं हैं। कोड को पूरी तरह से पर्याप्त संबंध के बिना लिखा जाता है कि इसे अक्सर कैसे कहा जाता है अजीब इंटरफेस या मान्यताओं / पूर्व शर्त।

— bri_o

3

@TrevorBoydSmith नाम रखने के लिए, मैंने सुना है कि "स्पाइक एंड स्टैबिलाइज़" कहा जाता है और हाँ, यह एक आसान तकनीक है जब यह पता चलता है कि कैसे कुछ करना है जो आप अभी तक नहीं जानते हैं।

— रबरडैक

13

एक भौतिक चीज़ बनाने और सॉफ्टवेयर लिखने के बीच समानताएँ बहुत कम हैं।

उस ने कहा, वहाँ एक बड़े पैमाने पर गौर करने लायक बात है:

"एक परीक्षण संलेखन" और "एक परीक्षण निष्पादित करने" के बीच अंतर है।

एक घर के निर्माण के उदाहरण में, आवश्यकताओं और परीक्षण करते शारीरिक buildout पूर्व में होना। और परीक्षण सूट के कुछ हिस्सों को लगातार चलाया जाता है - कई एजेंटों द्वारा भी! जब बिल्डर एक 2x4 उठाता है, तो वह तुरंत "स्वचालित रूप से" एक ध्वनि 2x4 की तरह दिखने वाली उसकी धारणा के खिलाफ इकाई का "परीक्षण" करता है। वह इसे लेने के बाद लेखक की आवश्यकताओं को पूरा नहीं करता है; वह इस पर पहले से मौजूद चेक चलाता है।

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

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

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

और यह ठीक है। कठोर परीक्षणों से पहले हर चीज की जरूरत नहीं होती है।

tl; डॉ

भले ही निर्माण! = लेखन सॉफ्टवेयर: निर्माण एक परीक्षण संचालित फैशन में काम करता है। हर इकाई के लिए "गुजर" की स्थिति कर उनके buildout पूर्व में होना।

"परीक्षण लेखन" के साथ "निष्पादन परीक्षणों" को भ्रमित न करें।

सब कुछ टीडीडी होने की आवश्यकता नहीं है।

— svidgen
स्रोत

मुझे कोड मिलता है! = भौतिक रूप से इसकी सादृश्यता। लेकिन यह वास्तव में मेरे लिए थोड़ा और साफ करता है। जैसा कि मेरी अन्य टिप्पणी बताती है कि मैं सोच रहा हूं कि क्या यह परीक्षण पहले वापस जाने और अब बड़े बदलाव करने की इच्छा में बाधा उत्पन्न करता है?

— nerdlyist

@nerdlyist एक तरह से, हाँ। लेकिन, यदि आपके परीक्षण "सही" चीजों की जांच कर रहे हैं, तो यह एक "बाधा" है जो आप चाहते हैं ।

— svidgen

4

घर की उपमा पर वापस जाना: यदि आपका ग्राहक अचानक दरवाजे की एक अलग शैली में स्वैप करना चाहता है, और इसमें समान आयाम नहीं हैं, तो दरवाजे के आसपास की आवश्यकताओं और उद्घाटन के आयाम बदल जाएंगे, और काम को उन परीक्षणों को बदलने की आवश्यकता है। "कार्यान्वयन परिवर्तन करने के लिए आवश्यक कार्य को दर्पण करना चाहिए। लेकिन, बहुत सारे परीक्षण हैं जो नहीं बदलेंगे: दरवाजा खुला होना चाहिए और बंद होना चाहिए, लॉक होना चाहिए और बंद होने पर उद्घाटन में P% वायुरोधी होना चाहिए ... बहुत सारे परीक्षण जो "बाधा" नहीं बदलते हैं शारीरिक रूप से उचित परिवर्तन ।

— svidgen

1

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

— nerdlyist 16

1

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

— 18

11

आप बकवास विचार पर विश्वास करने के जाल में गिर गए हैं कि सॉफ्टवेयर लिखना एक घर बनाने के अनुरूप है। यह नहीं है। यह आर्किटेक्ट ड्राइंग और संरचनात्मक इंजीनियरों की गणना बनाने के लिए अधिक अनुरूप है।

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

सॉफ्टवेयर इंजीनियरिंग के लिए चीजें बेहतर हैं। घर के निर्माण के समतुल्य कंपाइलर आपके कोड को किसी प्रकार की संकलित इकाई (लाइब्रेरी, ऐप, वेब ऐप आदि) में बदल देता है। दिन में सैकड़ों बार ऐसा करना बहुत तेज और सस्ता है। नतीजतन, यह आपके द्वारा सुविधाओं को जोड़ने के रूप में घर को बार-बार पुनर्निर्माण करने का कोई मतलब नहीं है, और केवल परीक्षण करने के लिए अंत में निरीक्षक (क्यूए) में कॉल करें। इसके बजाय, यदि आप उन जांचों को स्वचालित करते हैं, तो आप निरीक्षक के पास हर बार आपके द्वारा पुनर्निर्माण किए जाने वाले हर चीज़ का पुन: निरीक्षण कर सकते हैं।

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

— डेविड अरनो
स्रोत

1

मैं देख रहा हूँ कि आपने बिल्डिंग कंट्रोल से निपट लिया है ... :)

— जूल्स 16

5

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

— जियोर्जियो

2

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

— केविन क्लाइन

7

सबसे पहले और सबसे आगे की लागत उतनी अधिक नहीं है जितना आपको लगता है कि यह है । हां, यदि आप कोई परीक्षण नहीं करते हैं तो आप परीक्षण को संबोधित करने में अधिक समय व्यतीत करते हैं। लेकिन अगर आप "परीक्षण के बाद" विधि करते हैं तो आप वास्तव में क्या बर्बाद कर रहे हैं? मान लीजिए कि TDD को 10 घंटे लगते हैं, और DDT को 6 घंटे लगते हैं। आपकी "अतिरिक्त" अग्रिम लागत केवल 4 घंटे है। अब यदि आप एक कोड मेट्रिक या आवश्यकता जैसे 90% कवरेज लागू करते हैं, तो आपका TDD और DDT लागतों में और भी करीब हो जाता है।

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

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

तुम्हें पता नहीं है कि यह काम नहीं करता है। एक परीक्षण सूट के बिना आप नहीं जानते कि क्या आपका कोड आपके सोचने के तरीके पर काम कर रहा है या यदि यह सिर्फ काम करता हुआ प्रतीत होता है।

var foo = function(in) {
    if(in == 0) {
      return true
    }
}

अब आपके आवेदन पर सभी आपको कॉल if(foo()){ doStuff() }करते हैं जब मैं फ़ू को ठीक करता हूं तो क्या होता है?

var foo = function(in) {
    if(in === 0) {
      return true
    }
}

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

मैं सिर्फ यह नहीं देखता कि मुझे अपने सभी तरीकों को कैसे जानना चाहिए और जब तक मेरा कोड नहीं है तब तक कैसे काम करेगा।

ठीक है, आप करने वाले नहीं हैं। आपको एक परीक्षण लिखना चाहिए जो परीक्षण करता है कि कुछ इकाई काम करती है। यदि आपको ऐसा लगता है कि आप उन चीजों का परीक्षण कर रहे हैं जिनके बारे में आप संभवतः नहीं जानते हैं तो आप बहुत बड़ा सोच रहे हैं, या परीक्षण बहुत छोटा है।

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

अब अगर आप एक परीक्षण लिख रहे हैं जो कहते हैं कि house.isSecure () सही है जब सभी दरवाजे और खिड़कियां बंद हो जाती हैं। पहले दरवाजे या खिड़कियों को देखे बिना फिर आप बहुत बड़ा सोच रहे हैं।

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

संक्षेप में, आपकी समझ (सूची) कि टीडीडी को कैसे काम करना चाहिए। आपको कभी भी 2/100 पास नहीं होना चाहिए। आपके पास 1/1 पास होना चाहिए, फिर 2/2 पास होना, फिर 3/3 पास होना, फिर 4/4 पास होना, और इसी तरह।

आपके लिए एक संशोधित सूची

सभी विशिष्टताओं को प्राप्त करें
एक विनिर्देश चुनें
झसे आज़माओ
इसे कोड करें
झसे आज़माओ
यदि परीक्षण 7 पर चलते हैं तो 4 पर जाते हैं
यदि आपने सभी ऐनक किए हैं, तो 8 पर जाएं 2 पर जाएं
उपभोक्ता के साथ विनिर्देशों की समीक्षा करें, और जहां आवश्यक हो, नए विनिर्देशों को जोड़ें। यदि सही ढंग से किया गया है तो आपको कोई भी परीक्षण नहीं बदलना चाहिए। बस नए जोड़ें। कभी-कभी आवश्यकताएं पूरी हो सकती हैं और आपको ऐसे परीक्षणों को जोड़ना पड़ता है जो पहले के परीक्षणों से टकराते हैं, लेकिन आपको शायद ही कभी परीक्षणों को बदलना होगा।

— coteyr
स्रोत

2

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

— 21

1

मुझे भी यह उत्तर पसंद है। ध्यान दें कि हम यह भूल जाते हैं कि हम वास्तव में कितना समय मैन्युअल रूप से परीक्षण निष्पादित करने में खर्च करते हैं: संपादित करें, संकलन करें, मैन्युअल रूप से डिबग के माध्यम से कदम दोहराएं। TDD इसमें से बहुत कुछ स्वचालित करता है।

— टेक्नोफाइल

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

— एंट पी।

4

कुछ चाबियाँ हैं जो मुझे लगता है कि अन्य उत्तर गायब हैं।

तीन फायदे

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

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

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

(अतिरिक्त कोड एक समस्या है जिसे मैंने एक उत्पाद में देखा है जिस पर मैं काम करता था। गंभीर समस्याएं कोड से आती हैं जो किसी ने भी नहीं पूछीं, लेकिन कुछ डेवलपर ने सोचा कि यह अच्छा होगा।)

लागत विश्लेषण

तो कुछ मायनों में, आप सही हैं। घर बनाते समय हम इस रणनीति से दूर नहीं हो सकते थे। यह बहुत महंगा होगा। लेकिन सॉफ्टवेयर एक घर नहीं है। सॉफ्टवेयर सस्ता है।

एक घर के साथ एक सादृश्य घर बनाम एक सॉफ्टवेयर संकलक के संयोजन का श्रम है।

एक गैर-टीडीडी दुनिया में, डेवलपर्स अभी भी पुनरावृति करते हैं। हम एक कोड का पालन करते हैं -> संकलन -> रन -> परीक्षण चक्र। हम पहले से ही एक मॉडल में हैं जो घर बनाने से काफी हद तक भटकता है। यदि आपका निर्माण करने वाले लोग एक चौखट का निर्माण करते हैं, तो एक द्वार का निर्माण करें, फिर फ्रेम का पुनर्निर्माण करना होगा क्योंकि द्वार इसके लिए बहुत बड़ा है, आपको लागत की समस्या होगी। इस प्रकार, आप यह सुनिश्चित करने के लिए अधिक समय बिताते हैं कि आपको सब कुछ सही मिले। प्रोग्रामिंग में, अधिकांश परियोजनाओं को सेकंड या मिनटों में संकलित किया जा सकता है, इसलिए इससे कोई फर्क नहीं पड़ता कि कुछ जल्दी अपूर्ण है। समय से पहले तुच्छ मामलों की सोच आम तौर पर recompiling की लागत को पछाड़ देती है। इस प्रकार, हम हर समय recompile करते हैं।

टीडीडी एक ही सिद्धांत है, सिर्फ घुमाया जाता है ताकि परीक्षण आगे बढ़े। यदि परीक्षण को सुपर सस्ता बनाया जा सकता है (तो यह सब कुछ सेकंड में चलता है), तो बड़ी तस्वीर के माध्यम से सोचने की लागत, एक एकल बिग-बैंग कोडिंग चलना में संपूर्ण समाधान, रिफैक्टिंग की लागत को पछाड़ देता है।

के सिवाय...

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

— ब्रैंडन
स्रोत

1

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

— टेक्नोफाइल

4

मैं इस बारे में बहुत आश्चर्य करता था जब तक कि मैंने टीडीडी की कुछ परियोजनाएं नहीं कीं। एक बहुत ही संक्षिप्त और व्यापक व्याख्या है, जो मेरे साथ ऐसा करते समय मेरे सामने आई थी:

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

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

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

इसलिए TDD यह देखने का एक चरम तरीका है कि आप अपने काम को कैसे मान्य करते हैं।

— joojaa
स्रोत

4

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

जब आप कुछ नया लिख रहे होते हैं, तो कुछ ऐसा जो आपने पहले कभी नहीं किया है, टीडीडी और टीडीडी नहीं करने के बीच कोई महत्वपूर्ण अंतर नहीं है।

आम तौर पर आप क्या करेंगे एक विचार का पता लगाने के लिए कोड का एक छोटा सा टुकड़ा लिखा जाता है फिर "परीक्षण" के लिए कुछ हार्डकोड बिट्स जोड़ें और फिर इसे संकलित करें और / या निष्पादित करें। यदि यह काम करता है तो आप हार्डकोडेड सामान को हटा देंगे और पैरामीटर, उदाहरण चर आदि जोड़कर कोड को सामान्य कर देंगे।

इसके बारे में सोचो। टीडीडी के रूप में ठीक यही काम है। एकमात्र अंतर TDD में है जिसे आप "परीक्षण" बिट्स को किसी अन्य फ़ाइल में अलग से लिखेंगे और अंत में उन्हें हटा नहीं सकते। TDD में आप अपना टेस्टिंग कोड रखते हैं ।

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

— slebetman
स्रोत

2

परीक्षण-संचालित विकास (TDD) और विकास-संचालित परीक्षण (DDT) के बारे में सब क्यों चुस्त है?

बस यहाँ में चहकते हुए क्योंकि मुझे लगता है कि सवाल एक तथ्य ("चुस्त सब TDD के बारे में है") का सुझाव देता है जो मुझे आपत्तिजनक लगता है। सभी उत्तर इस तथ्य को समान रूप से लेते प्रतीत होते हैं। वे अच्छे उत्तर हैं यदि आप मानते हैं कि चुस्त मुख्य रूप से टीडीडी (उर्फ, यूनिट स्तर पर परीक्षण) के बारे में है।

https://en.wikipedia.org/wiki/Agile_software_development#Agile_methods एक अच्छे दर्जन या अधिक विभिन्न विकास मॉडल को सूचीबद्ध करता है।

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

तो मेरा जवाब ist:

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

मैं बल्कि पूर्ण BDD / FDD कवरेज और पूर्ण इकाई परीक्षण कवरेज के साथ एक से अधिक कोई इकाई परीक्षण और पूर्ण-स्टैक परीक्षण के साथ कोई अनुप्रयोग नहीं था।

(टीडीडी का अपना स्थान है, उदाहरण के लिए एपीआई में, लेकिन यह वह नहीं है जिसके बारे में हम यहां बात कर रहे हैं।)

फिर से, मैं यहां अन्य सभी उत्तरों को नीचा दिखाने की कोशिश नहीं कर रहा हूं, बस यह इंगित करते हुए कि प्रश्न संकीर्ण रूप में तैयार किया गया है, और क्षेत्र में बहुत कुछ है।

— AnoE
स्रोत

मैं दूसरे के बारे में जानता था, लेकिन उस समय राइटिंग डीडीटी सिर्फ अधिक समझ में आता था। TDD एपीआई के लिए बेहतर क्यों है, इस पर विस्तार से ध्यान दें। एमवीसी के साथ एक वेब क्लाइंट के कहने पर इसका उपयोग कैसे होगा?

— nddlyist 16

1

एपीआई में यह बहुत महत्वपूर्ण है कि वे एक बहुत विस्तृत अनुबंध का पालन करें ; प्रत्येक विधि कॉल को सही तरीके से उपयोग करने के लिए उपयोगकर्ताओं (जो अन्य प्रोग्राम हैं) के लिए बहुत पूर्वानुमान योग्य व्यवहार करना चाहिए। यह वह जगह है जहाँ इकाई परीक्षण वास्तव में चमकता है। OTOH, एक एप्लिकेशन में, उन विशेषताओं के लिए सबसे महत्वपूर्ण है जिन्हें आपके मानव उपयोगकर्ताओं को आवश्यकतानुसार काम करना है। निश्चित रूप से, आपके "इंटर्नल" बेहतर होने के साथ-साथ सही भी हैं, लेकिन प्रत्येक व्यक्तिगत पद्धति का परीक्षण करने के बजाय "एंड टू एंड" कार्यक्षमता का अच्छा कवरेज होना आवश्यक है (यानी, यूआई से डीबी और बैक में)। मानव अंत उपयोगकर्ता वैसे भी नहीं देखेंगे)।

— एनओई

बेशक, सभी यहां अलग-अलग डिग्री में हैं - यहां यूनिट परीक्षणों की एक चापलूसी करना समझदारी हो सकती है, साथ ही अगर आपके पास कहीं बहुत जटिल तरीके / कक्षाएं होनी चाहिए (उदाहरण के लिए: जियोकॉर्डिनेट के बीच की दूरी की गणना करना); लेकिन थोक (जैसे, व्यावसायिक अनुप्रयोगों में) समग्र वर्कफ़्लो है।

— एनओई

0

हालाँकि आप इसे अक्सर इस तरह से लिखते हुए नहीं देखते हैं, चंचलता के पीछे तर्क का बहुत कुछ यह है कि इसे पहली बार लिखने से बेहतर है दोबारा लिखना। हर बार जब आप कोड को फिर से लिखते हैं तो आप कोड में सुधार करते हैं और खुद को सुधारते हैं। इसे "राइट" करना पहली बार धीमा और अधिक भंगुर हो जाता है।

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

हालांकि, कोड परीक्षण के लिए निरीक्षण करना एक अच्छा सादृश्य नहीं है। सॉफ्टवेयर में हम उस बिंदु पर भी नहीं हैं जहाँ हमारे पास अच्छे निरीक्षक हैं (विभिन्न कौशल स्तरों के अपने साथियों को छोड़कर)। हमारे पास नियमों के अलावा निरीक्षण करने के लिए नियम नहीं हैं, शायद, कुछ अधिकतर-मनमाने "कोडिंग मानकों" (जो आपके पेंट के रंग और संरचना की तुलना में आपके लॉन लेआउट का परीक्षण करना अधिक पसंद करते हैं)।

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

यदि आपको हमारे पिछले वास्तुकला ज्ञान, पैटर्न, नियमों और गणित के सदियों के बिना पुलों की एक श्रृंखला का निर्माण करना था, जो कि वर्तमान में हमारे पुलों को साबित करना है कि हम उन्हें बनाने से पहले काम करेंगे, तो आप शायद अपने पुलों का परीक्षण और पुनर्निर्माण एक बहुत कुछ करेंगे।

अंत में एक गैर-सादृश्य बिंदु - सॉफ़्टवेयर के साथ हर बार जब आपको अपने कोड के एक हिस्से को फिर से लिखने की अनुमति दी जाती है तो आप अपने कोड और अपने कौशल दोनों में काफी सुधार करते हैं। कोड को फिर से लिखने के लिए आप कर सकते हैं हर मौका ले लो। TDD एक महान बहाना हो सकता है।

— बिल के
स्रोत