2009-11-29 20 views
6

मुझे पता है कि टीडीडी बहुत मदद करता है और जब आप पहली बार परीक्षण बनाते हैं और फिर कार्यक्षमता को कार्यान्वित करते हैं तो मुझे विकास की यह विधि पसंद है। यह बहुत स्पष्ट और सही तरीका है।अस्पष्ट आवश्यकताओं के साथ टीडीडी

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

मुझे दो समस्याएं दिखाई देती हैं: 1. मैं जितनी जल्दी हो सके परिणाम को देखना चाहता हूं मेरे विचार सही या गलत हैं। यूनिट परीक्षण इस प्रक्रिया को धीमा कर देते हैं। तो अक्सर ऐसा होता है कि कोड समाप्त होने के बाद मैं यूनिट परीक्षण लिखता हूं जिसे खराब पैटर्न माना जाता है। 2. मैं पहली बार परीक्षण लिखने अगर मैं दो बार या अधिक बार, लेकिन यह भी परीक्षण न केवल कोड को फिर से लिखने की जरूरत है। इसमें काफी समय लगता है।

क्या कोई मुझे बता सकता है कि ऐसी स्थिति में टीडीडी कैसे लागू किया जा सकता है?

अग्रिम धन्यवाद!

उत्तर

12

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

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

2

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

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

7

मुझे लगता है कि TDD स्थिति इस तरह का में विशेष रूप से अच्छी तरह से काम करता है; वास्तव में, मैं कहूंगा कि अस्पष्ट और/या बदलती आवश्यकताओं को वास्तव में बहुत आम है।

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

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

-1

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

जब आप कुछ करते हैं तो आपके पास परीक्षण होना चाहिए।

+0

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

0

यहां एक ब्लॉग पोस्ट है जिसे मैंने टीडीडी के उपयोग को बहुत ही पुनरावर्तक डिजाइन प्रक्रिया पैमाने पर समझाते हुए शक्तिशाली पाया: http://blog.extracheese.org/2009/11/how_i_started_tdd.html

1

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

कुछ चीजें आप अपने परीक्षण अधिक बदलने के लिए प्रतिरोधी बनाने के लिए कर सकते हैं:

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

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

  3. अपने यूनिट परीक्षण को छोटा और पृथक बनाएं - प्रत्येक परीक्षण को आपके कोड के केवल एक पहलू की जांच करनी चाहिए और बाहरी वस्तुओं से परीक्षण को परीक्षण करने के लिए मॉकिंग/अलगाव फ्रेमवर्क का उपयोग करना चाहिए।

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

2

वहाँ से दूर हो रही है कोई है - आप का आकलन कर रहे है, तो कब तक यह कोड करने के लिए ले जाता है बस कितनी देर तक यह ले जाता है कक्षाएं, आदि लिखने के द्वारा, तो यह लंबे समय तक TDD साथ ले लेंगे। यदि आप अनुभव कर रहे हैं तो यह लगभग 15% जोड़ देगा, यदि आप नए हैं तो कम से कम 60% अधिक समय लगेगा यदि अधिक नहीं।

लेकिन, कुल मिलाकर आप जल्दी हो जाएंगे। क्यूं कर?

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

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

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

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

5

आईएमएचओ, आपकी मुख्य समस्या तब होती है जब आपको कुछ कोड हटाना पड़ता है। यह कचरा है और यह पहले संबोधित किया जाएगा।

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

जोखिम लागू करना और प्रोटोटाइप को शिप करना है।

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

आप किस विकास प्रक्रिया का उपयोग कर रहे हैं? यह अजीब लगता है क्योंकि आपके पास पुनरावृत्ति हो रही है, लेकिन ऐसे वातावरण में नहीं जो पूरी तरह से इसका समर्थन करती है।

+0

+1 - यह मेरा पहला विचार भी था। – TrueWill

+0

मुझे कोड हटाने से प्यार है। इसका मतलब है कि मैंने जिस कोड पर काम कर रहा हूं उसे सरल बना दिया है। – kyoryu

0

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

2

टीडीडी, किसी के लिए, प्रारंभिक विकास को धीमा कर देगा। इसलिए, अगर शुरुआती विकास की गति 1-10 के पैमाने पर 10 है, तो टीडीडी के साथ यदि आप कुशल हैं तो आपको लगभग 8 मिल सकते हैं।

यह के बाद विकास है जो दिलचस्प हो जाता है। जैसे-जैसे परियोजनाएं बड़ी होती हैं, विकास दक्षता आम तौर पर गिरती है - अक्सर एक ही पैमाने पर 3 तक। टीडीडी के साथ, अभी भी 7-8 रेंज में रहना बहुत संभव है।

अच्छी पढ़ाई के लिए "तकनीकी ऋण" देखें। जहां तक ​​मेरा संबंध है, यूनिट परीक्षण के बिना कोई भी कोड प्रभावी रूप से तकनीकी ऋण है।

0

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

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

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

संबंधित मुद्दे