45

यदि आप TDD (Test-Driven Development) नहीं करते हैं तो क्या अपने आप को (या अपनी टीम को) "फुर्तीली" कहना सही है?

agile tdd

— CraigTP
स्रोत

2

यदि आप सभी उत्तर पढ़ते हैं, तो वे सभी सहमत होते हैं। आप टीडीडी किए बिना चुस्त होने का दावा कर सकते हैं , क्योंकि 'फुर्तीला' एक विशिष्ट पद्धति नहीं है। लेकिन मैंने नीचे कोई जवाब नहीं देखा, जिसमें कहा गया था कि "ओह हां, टेस्ट-फर्स्ट जरूरी नहीं है" ;-)

— स्टीवन ए। लोव

एक टीडीडी के बिना कर सकता था, लेकिन खुद को अपंग और बर्फ में 7 मील क्यों चलना था?

— जॉब

3

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

— क्रेगटीपी

2

आप "फुर्तीले" होने की इतनी परवाह क्यों करते हैं ??? क्या आपके पास चिंता करने के लिए कुछ और महत्वपूर्ण नहीं है, जैसे कि, सॉफ्टवेयर लिखना जो आपके ग्राहकों को प्रसन्न करता है?

— xpmatteo

1

@ शादोचेज़र मुझे वही मिलता है जो आप कह रहे हैं, लेकिन फुर्तीले अंक # 1 के बारे में एक पल के लिए शैतान के वकील की भूमिका निभाने के लिए, अगर मैं एक ऐसी टीम में होता, जिसने एक जलप्रपात शैली का विकास किया था, लेकिन हम उस के सदस्यों के बीच बहुत संचार और सहयोग करते थे टीम, यह हमें चुस्त बना देगा?

— क्रेगटीपी

50

हां, हां, हां, लाख बार हां।

चंचलता एक दर्शन है, टीडीडी एक विशिष्ट पद्धति है।

अगर मैं वास्तव में योग्य होना चाहता था, तो मैं केवल यह बता सकता हूं कि xDD की काफी भिन्नताएँ हैं - जो कि उनके अधिवक्ता गहराई से समझाएंगे, TDD नहीं हैं - लेकिन वे अभी भी पहले परीक्षण के लिए पर्याप्त रूप से बंधे हुए हैं ताकि धोखा हो।

तो यह कहता है - आप "परीक्षण पहले" विकास किए बिना चुस्त हो सकते हैं (जिस तरह से घोटाले काम करता है - वहां कहीं भी नहीं है कि आप कोड कैसे लिखते हैं, इसके बारे में कुछ निर्दिष्ट नहीं हैं)। एक कंबन बोर्ड को देखें, सभी प्रकार की चुस्त कार्यप्रणाली को देखें।

क्या आपको यूनिट टेस्ट चाहिए? बेशक, आप सभी प्रकार के कारणों से करते हैं - और आप अच्छी तरह से एक तर्क दे सकते हैं कि आप इकाई परीक्षणों के बिना चुस्त नहीं हो सकते (हालांकि मुझे संदेह है कि आप हो सकते हैं) - लेकिन आपको उन्हें पहले लिखने की ज़रूरत नहीं है चुस्त।

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

ऐसा लगता है कि अन्य (अधिक ठोस प्रतिनिधि के साथ) एक समान राय है ...

http://www.twitter.com/unclebobmartin/status/208621409663070208

@unclebobmartin: http://t.co/huxAP5cS हालांकि TDD और OOD के बिना एजाइल करना असंभव नहीं है, लेकिन यह मुश्किल है। TDD के बिना पुनरावृत्ति दर ...

(ट्वीट में लिंक लिंक्डइन पर पूरा जवाब है)

— Murph
स्रोत

2

+1 इसके लिए आप सामान्य तरीके से कार्य करते हैं, इसलिए नहीं कि आप उस या उस पद्धति का उपयोग करते हैं।

10

इकाई परीक्षणों को चुस्त होना आवश्यक है। यह सिर्फ इतना है कि आपको उन्हें पहले लिखना नहीं है।

— मैक्नील

6

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

— मार्टिन विकमैन

4

@ मेरीन: घोषणापत्र में सभी विकास विधियों का उल्लेख नहीं है

— स्टीवन ए। लोव

4

मैंने परियोजनाओं को चलाने के लिए SCRUM का उपयोग करके अभी एक बड़ी कंपनी में काम शुरू किया है। मैं जिस प्रोजेक्ट पर काम कर रहा हूं वह SCRUM (सही ढंग से!) है, लेकिन कोड में यूनिट टेस्ट नहीं हैं। इकाई परीक्षण नहीं होने से SCRUM का उपयोग करने या चुस्त होने की क्षमता पर प्रभाव नहीं पड़ता है, लेकिन यह कोड की गुणवत्ता में विश्वास करने के साथ-साथ जल्दी से बदलाव (आत्मविश्वास के साथ) करने की मेरी क्षमता को प्रभावित करता है। चंचलता में उत्पन्न होने वाले दस्तावेज़ीकरण की कमी को देखते हुए, मुझे लगता है कि पहले, आखिरी या बीच में परीक्षण करना, शेष आयु (परिवर्तन के लिए) के लिए एक बड़ा लाभ है।

— रॉ ग्रे

19

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

तो हाँ, आप TDD या इकाई परीक्षण किए बिना चुस्त हो सकते हैं।

मैं हालांकि यह सिफारिश नहीं होगा ...

— मार्टिन विकमन
स्रोत

2

@Martin: अच्छी तरह से कहा - घोषणापत्र में कोई विकास प्रथाओं को निर्दिष्ट नहीं किया गया है। यह एक मिशन स्टेटमेंट है, कार्यप्रणाली नहीं।

— स्टीवन ए। लोव

4

@ मर्टिन: फुर्तीली प्रक्रिया और चुस्त सिद्धांतों में अंतर होता है। यदि आप एक चुस्त प्रक्रिया का नाम दे सकते हैं जिसमें परीक्षण नहीं हैं, तो कृपया ऐसा करें।

— मैक्नील

@ मैकनेइल: स्क्रैम में परीक्षण नहीं होते हैं।

— मार्टिन विकमन

2

@ मर्टिन: फिर से, स्क्रैम एक परियोजना प्रबंधन पद्धति है, न कि एक सॉफ्टवेयर विकास पद्धति। स्क्रैम का उपयोग आमतौर पर एक्सपी जैसे फुर्तीली विकास पद्धति के साथ किया जाता है, लेकिन इसके लिए कोई विकल्प नहीं है

— स्टीवन ए। लोव

@ उत्तर: मेरे उत्तर को स्पष्ट करने के लिए धन्यवाद कि स्क्रैम में परीक्षण जैसी कोई विकास पद्धति नहीं है। मुझे लगता है कि बिंदु अब तक अच्छी तरह से अंकित है :-)

— मार्टिन विकमन

11

हाँ ,

चुस्त मूल्यों में से एक को देखो:

व्यक्तियों और प्रक्रियाओं और उपकरणों पर बातचीत

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

मैं इसे इस तरह सम्‍मिलित करूंगा:

आज TDD फुर्तीले होने के लिए डिफैक्टो-स्टैंडर्ड है
टीडीडी के बिना चुस्त होने के तरीके हो सकते हैं

— FabianB
स्रोत

5

मैं कहता हूँ

कोई [प्रकार] नहीं

यदि आप मूल स्रोत पर वापस जाते हैं तो http://en.wikipedia.org/wiki/Extreme_Programming TDD प्रक्रिया के लिए मौलिक है; परीक्षण आवश्यकताओं के विनिर्देशों और झरने के उपयोग के मामलों की जगह लेते हैं, जीवित दस्तावेज और कामकाजी उदाहरणों के रूप में कार्य करते हैं, आदि वे अपरिहार्य हैं।

हालाँकि, अब चारों ओर तैरने वाले 'फुर्तीले' के इतने अलग-अलग स्वाद हैं कि यह पूरी तरह से संभव है कि उनमें से एक टीडीडी बच जाए

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

कार्य सॉफ्टवेयर प्रगति का प्राथमिक माप है।

तथा

चंचल प्रक्रियाएं सतत विकास को बढ़ावा देती हैं। प्रायोजकों, डेवलपर्स और उपयोगकर्ताओं को अनिश्चित काल तक निरंतर गति बनाए रखने में सक्षम होना चाहिए।

मेरे लिए, इन दो सिद्धांतों का मतलब है अगर टीडीडी की आवश्यकता नहीं है - कम से कम मुझे इसके बिना उन्हें प्राप्त करने का कोई अन्य तरीका नहीं पता है!

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

संपादित 3: मैं अंत में यह पता लगा लिया कि मुझे मर्फ़ के बहुत ही लिखित उत्तर के बारे में क्या परेशान करता है। यह धारणा है कि कोई वास्तव में ऐसा किए बिना "एजाइल" हो सकता है । और "कर रहा है" (जैसा कि ऊपर दिखाया गया है) को बहुत ज्यादा TDD की आवश्यकता होती है।

— स्टीवन ए लोव
स्रोत

1

कहीं उस पृष्ठ पर TDD या टेस्ट पहले metioned है सिवाय एक संबंधित पृष्ठ पर एक लिंक के रूप में।

— मर्फ़

2

मैंने 2000-2001 में एक चरम प्रोग्रामर के रूप में काम किया। हां हमने यूनिट टेस्ट लिखे, लेकिन लगभग हमेशा पहले कोड लिखा, और फिर बाद में कोड का परीक्षण किया।

— माइकल शॉ

1

शब्दों का गलत चुनाव। आइए इसे फिर से लिखें: एजाइल सिर्फ एक्सट्रीम प्रोग्रामिंग नहीं है; Scrum और Kanban को चुस्त कार्यप्रणाली के रूप में भी देखा जा सकता है और उनमें से कोई भी XP की तरह TDD के उपयोग को लागू नहीं करता है

— t3mujin

2

@ मर्फ़: पहला वाक्य यह सब मायने रखता था। @Ptolemy: तो फिर यह गलत था ;-) @ t3mujin फिर होगा मजाक!

— स्टीवन ए। लोव

4

+1: मुझे पार्टी में देरी हो रही है, लेकिन यह एकमात्र उपयोगी उत्तर है। यह कहना कि हम परीक्षण के बिना टीडीडी कर सकते हैं, यह कहने जैसा है कि हम ड्राइवर परीक्षा में उत्तीर्ण हो सकते हैं, बिना यह जाने कि कैसे ड्राइव करना है। हां, यह संभव है, लेकिन शायद ही ऐसा हो। जैसे माइकल फेदर ने कहा, "लिगेसी कोड बिना परीक्षणों के कोड है"। और कोड है कि परिभाषा के अनुसार, बनाए रखने के लिए कठिन है, यह भी च **** के साथ काम करने के लिए असंभव असंभव है जब आप एक चुस्त, चलने की प्रक्रिया का उपयोग करें।

— रासना

2

सख्ती से, आप चुस्त घोषणापत्र का पालन करके चुस्त हैं । व्यवहार में, एक कोड-आधार तब तक चुस्त नहीं होता जब तक कि उसके पास अच्छा परीक्षण कवरेज न हो। आप TDD कर सकते हैं और कार्यक्षमता के विकास के पहले / दौरान परीक्षण लिख सकते हैं या इसके विकसित होने के बाद कार्यक्षमता के लिए परीक्षण लिख सकते हैं। यह आमतौर पर आसान और अधिक प्रभावी है, हालांकि इसे टीडीडी तरीका है।

— Alb
स्रोत

2

आप चुस्त हो सकते हैं, लेकिन सुधार के लिए शायद जगह है।

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

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

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

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

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

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

इसलिए टीडीडी ओवरप्रोडक्शन से बचने में मदद करता है, जिससे टीम यथासंभव प्रभावी हो सकती है, जो एक मुख्य चुस्त सिद्धांत भी है।

कार्य सॉफ्टवेयर प्रगति का प्राथमिक माप है

— पीट
स्रोत

1

क्या आप TDD (परीक्षण संचालित विकास) किए बिना चुस्त हो सकते हैं?

संक्षिप्त उत्तर: हां।

दीर्घ उत्तर: इस प्रश्न के बहुत अच्छे उत्तर हैं और बहुत अच्छे संदर्भ हैं। मैं उन बिंदुओं पर बहस करने की कोशिश नहीं करूंगा।

मेरे अनुभव में, Agile हाथ में परियोजना के लिए लीन-नेस के सही स्तर को चुनने के बारे में है। लीन-नेस से मेरा क्या मतलब है? और, मैं इसे इस उत्तर में क्यों लाऊं?

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

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

क्या होता है जब उपरोक्त आपूर्ति श्रृंखला में शिपिंग के लिए महाप्रबंधक को बताया जाता है कि उसे हर साल $ 1 मिलियन वार्षिक बोनस मिलेगा कि उसके पास बेड़े में 10 से कम ट्रक हैं? वह तत्काल बेड़े को 9 ट्रकों को काट देगा। इस "भयानक" परिदृश्य में, यह वेयरहाउस में संग्रहीत माल की मात्रा को बढ़ाएगा (उस नोड में लागत को बढ़ाकर)। और, यह स्टोर मोर्चों को "भूखा" रखेगा।

तो, समग्र आपूर्ति श्रृंखला ग्रस्त है अगर स्थानीय अनुकूलन पूरे के विचार के बिना अनुमति है।

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

और इसलिए, आपने पूछा: क्या आप TDD (परीक्षण संचालित विकास) किए बिना चुस्त हो सकते हैं?

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

एक पसंदीदा लेखक को उद्धृत करने के लिए ... जेआरआर टोल्किन

अंगूठियों का मालिक। रिंगों की फैलोशिप। पीजी 94 'और यह भी कहा जाता है', फ्रोडो ने जवाब दिया, 'काउंसिल के लिए कल्पित बौने के लिए नहीं, क्योंकि वे दोनों नहीं और हाँ करेंगे।'

तो, अंत में, ... यह निर्भर करता है। आपको प्रश्न का उत्तर देना चाहिए। कौन सा पथ सबसे अधिक कुशलता से आपको आपके इच्छित लक्ष्य तक ले जाएगा।

टीडीडी को या टीडीडी को नहीं। यह सवाल बना हुआ है। :-)

पुनश्च - मैं एक अन्य साइट पर भी इस जवाब को दोहरा रहा हूं। https://www.ibm.com/developerworks/mydeveloperworks/blogs/c914709e-8097-4537-92ef-8982fc416138/?maxresults=15&sortby=4&lang=en

— एम केविन मैकहॉग
स्रोत

1

एक महल की तुलना में इंजीनियरिंग।

चंचल महल

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

टीडीडी कैसल

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

चंचल TDD कैसल

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

निष्कर्ष

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

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

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

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

— ली लौविरे
स्रोत

0

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

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

— जय गोडसे
स्रोत

क्या आप TDD (परीक्षण संचालित विकास) किए बिना चुस्त हो सकते हैं?

कोई [प्रकार] नहीं

चंचल महल

टीडीडी कैसल

चंचल TDD कैसल

निष्कर्ष

टिप्पणियाँ