टीडीडी बनाम यूनिट परीक्षण [बंद]

Question

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

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

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

एक संघर्षरत टीम को TDD में लाने का सबसे अच्छा तरीका क्या है? और यह विफल है कि क्या यह कोड लिखने के बाद भी इकाई परीक्षण लिखने के लायक है?

संपादित करें

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

जाँच करना

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

Comments

आपको यह धागा मददगार लग सकता है: stackoverflow.com/questions/917334/should-i-use-tdd

— Randolpho

FOLLOW UP के लिए +1। यह एक बेहतरीन कहानी है।

— कार्ल मैनस्टर

Answer 1

यदि टीम टीडीडी को लागू करने में आनाकानी कर रही है, लेकिन वे पहले कोई यूनिट टेस्ट नहीं बना रहे थे ... तो उनके कोड लिखे जाने के बाद यूनिट टेस्ट बनाकर उन्हें शुरू करें। यहां तक ​​कि कोड के बाद लिखे गए यूनिट टेस्ट भी किसी यूनिट टेस्ट से बेहतर नहीं हैं!

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

Comments

यह सही है कि टीम पहले कोई इकाई परीक्षण नहीं बना रही थी। यह पूर्ण TDD के लिए एक अच्छा कदम पत्थर की तरह लगता है।

— वाल्टर

इससे अधिक सहमत नहीं हो सकते। वास्तव में, मुझे लगता है कि मैंने कुछ महीने पहले इसी तरह के प्रश्न के लिए कुछ लिखा था। कहाँ है ... आह! stackoverflow.com/questions/917334/should-i-use-tdd/…

— Randolpho

Answer 2

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

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

Answer 3

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

Comments

मुझे आपका बहाव मिलता है, लेकिन मैं 50% परीक्षण कवरेज के साथ "100% पूर्ण पुस्तकालय" के बारे में सावधान हूं ... बस मेरे अनुभव से कि कुछ परीक्षणों द्वारा कवर नहीं किए गए कोड के हर टुकड़े में कम से कम एक बग होता है। या इसे दूसरे तरीके से रखने के लिए: लोग कोड के लिए परीक्षण लिखने से बचते हैं जो वास्तव में कुछ और परीक्षण से लाभान्वित होंगे :)

— हारून डिगुल्ला

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

— jcdyer

"100% पूर्ण पुस्तकालय" से आपका क्या तात्पर्य है। क्या आप इसे पूर्ण मानते हैं यदि छोटी गाड़ी? क्या आपने किया की परिभाषा में परीक्षण शामिल नहीं है?

— पास्कल थिवेंट

परीक्षण किया जा रहा है एक पर्याप्त हालत बग-मुक्त होने के लिए नहीं है

— पिता।

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

— डग नाइसेक

Answer 4

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

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

Comments

"वे क्या महसूस करते हैं" डेवलपर के रूप में मुझे याद नहीं है कि किसी भी (सही) इच्छा को कभी भी मेरी भावनाओं के माध्यम से किसी भी स्वचालित इकाई परीक्षण करने की इच्छा होती है, केवल मैनुअल वाले। मुझे नहीं लगता कि मैं अकेले परीक्षण से उत्साह की कमी कर रहा हूँ

— Gennady Vanin Геннадий Ванин

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

— आरोन दिगुल्ला

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

— DaFi4

Answer 5

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

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

Comments

+1: टेस्ट ड्रिवेन डेवलपमेंट का मतलब है कि डिज़ाइन को परीक्षण के विचार द्वारा संचालित किया गया था।

— एस.लॉट

+1। इकाई परीक्षण बाद में निश्चित रूप से आपकी मदद करेंगे लेकिन यदि आप इकाई परीक्षण नहीं लिखते हैं तो आप "परीक्षण योग्य डिजाइन" होने के लाभों को खो देंगे।

— नौफाल इब्राहिम

Answer 6

यदि वे IMO की तुलना में परीक्षण के लिए नए हैं तो पहले ही लिखे गए परीक्षण कोड को बंद कर दें और पहले परीक्षण लिखने के लिए धीरे-धीरे स्नातक हों। जैसा कि किसी ने टीडीडी और यूनिट परीक्षण के लिए नया सीखने की कोशिश की है, मैंने एक पूरी तरह से 180 करने और कोड से पहले परीक्षण लिखने के लिए अपनी मानसिकता को बदलने के लिए इसे कठिन पाया है, इसलिए मैं जो दृष्टिकोण ले रहा हूं वह 50-50 के मिश्रण की तरह है ; जब मुझे पता होगा कि कोड कैसा दिखेगा, तो मैं कोड लिखूंगा और फिर इसे सत्यापित करने के लिए एक परीक्षण लिखूंगा। ऐसी स्थितियों के लिए जहां मैं पूरी तरह से आश्वस्त नहीं हूं, फिर मैं एक परीक्षण के साथ शुरू करूंगा और अपने तरीके से पीछे की ओर काम करूंगा।

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

Answer 7

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

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

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

Answer 8

यह कुछ ऐसा है जो आपकी टीम की अपनी सफलताओं के साथ होगा, इससे पहले कि वे इस पर विश्वास करना शुरू करें। मुझे परवाह है कि जो कोई परवाह करता है, उसके लिए मेरे nUnit एपिफेनी के बारे में बताएगा:

लगभग 5 साल पहले मैंने एक परियोजना पर काम करते समय nUnit की खोज की थी। हमने V1.0 को लगभग पूरा कर लिया है और मैंने इस नए टूल को आज़माने के लिए कुछ परीक्षण किए हैं। हमारे पास बहुत सारे कीड़े थे (स्पष्ट रूप से!) क्योंकि हम एक नई टीम थे, एक तंग समय सीमा पर, उच्च उम्मीदें (ध्वनि परिचित?) आदि। वैसे भी हमें 1.0 में मिला और 1.1 पर शुरू हुआ। हमने टीम को थोड़ा सा फिर से संभाला और मुझे 2 देव मुझे सौंपे गए। मैंने उनके लिए 1 घंटे का डेमो किया और उन्हें बताया कि हमने जो कुछ भी लिखा था, उसके साथ एक परीक्षण का मामला था। हम लगातार 1.1 देव चक्र के दौरान टीम के बाकी हिस्सों को "पीछे" दौड़ाते थे क्योंकि हम अधिक कोड, इकाई परीक्षण लिख रहे थे। हमने अधिक काम करना समाप्त कर दिया, लेकिन यहाँ पे-ऑफ़ है - जब हम अंत में परीक्षण में आ गए तो हमारे कोड में ठीक 0 बग थे। हमने सभी को डिबग करने और उनके बग्स को ठीक करने में मदद की। पोस्टमॉर्टम में, जब बग मायने रखता है,

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

Comments

"परियोजना ने nUnit को अपनाया और यह जल्द ही सभी .Net परियोजनाओं के लिए कंपनी में फैल गया" और क्या होगा यदि एक उत्पाद / परियोजना में C #, Java, C ++, SQL सर्वर कोड हो?

— गेन्नेडी वनिन Геннадий Ванин

मुझे पता नहीं ... उत्पादन करने से पहले सभी घटकों का परीक्षण करने का एक तरीका खोजें? इकाई परीक्षण लाइव होने से पहले एक व्यापक परीक्षण योजना का केवल एक पहलू है। आप किसी भी परिदृश्य में छेद प्रहार कर सकते हैं।

— नो रिफंड्स नो रिटर्न

Answer 9

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

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

Answer 10

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

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

Answer 11

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

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

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

Answer 12

यदि आपके पास कोड लिखने से पहले डिज़ाइन सत्र हैं या आपको डिज़ाइन दस्तावेज़ का उत्पादन करना है, तो आप एक सत्र के मूर्त परिणाम के रूप में यूनिट टेस्ट जोड़ सकते हैं।

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

एक तरफ लेकिन बीडीडी भी ब्याज का हो सकता है

Comments

मैं बीडीडी से अनजान था। मुझे इसके बारे में और पढ़ना होगा।

— वाल्टर

Answer 13

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

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

Answer 14

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

रखरखाव प्रक्रिया के लिए टीम को लाइन पर लाने के लिए दृष्टिकोण होगा कि आप उन्हें ठीक करने से पहले बग्स को पुन: उत्पन्न करने के लिए JUnit परीक्षण लिखें, अर्थात

• बग की सूचना है
• जरूरत पड़ने पर JUnit टेस्ट क्लास बनाएं
• एक परीक्षण जोड़ें जो बग को पुन: पेश करता है
• अपना कोड ठीक करें
• वर्तमान कोड दिखाने के लिए परीक्षण चलाएं बग को पुन: उत्पन्न नहीं करता है

आप समझ सकते हैं कि "डॉक्यूमेंटिंग" बग इस तरह से उन बग्स को बाद में रेंगने से रोक देगा। यह एक ऐसा लाभ है जिसे टीम तुरंत अनुभव कर सकती है।

Answer 15

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

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

इस दृष्टिकोण ने अतीत में मेरे लिए कई बार काम किया है।

Answer 16

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

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

Answer 17

टीडीडी एक ऐसा उपकरण है जिसका उपयोग डेवलपर बेहतर कोड तैयार करने के लिए कर सकते हैं। मुझे ऐसा लगता है कि परीक्षण योग्य कोड लिखने की कवायद कम से कम उतनी ही मूल्यवान है जितनी कि परीक्षण। परीक्षण उद्देश्यों के लिए IUT (कार्यान्वयन के तहत परीक्षण) को अलग करने से आपके कोड को डिकूप करने का साइड इफेक्ट होता है।

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

मैं आमतौर पर स्वचालित स्वीकृति परीक्षणों को गैर-परक्राम्य बनाता हूं , लेकिन डेवलपर्स को टीडीडी को अपनाने की अनुमति दें क्योंकि यह उनके अनुरूप है। मेरे पास अपनी अनुभवी TDDers ट्रेन / मेंटर बाकी हैं और कई महीनों की अवधि में उदाहरण द्वारा उपयोगिता को "साबित" करते हैं।

यह उतना ही एक सामाजिक / सांस्कृतिक परिवर्तन है जितना कि यह तकनीकी है।