2008-10-29 16 views
20

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

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

मैंने पहले अपने यूनिट परीक्षण लिखने की कोशिश की है और यह उपयोगी हो सकता है, लेकिन यह मेरे लिए स्वाभाविक प्रतीत नहीं होता है।

+1

कृपया, इस समुदाय विकी को बनाएं, क्योंकि यह वास्तविक प्रश्न से मतदान से अधिक है। –

+0

यह अभी तक एक और सर्वेक्षण के बजाय एक असली सवाल होना चाहिए। मैं चाहता हूं कि उमर ने चुनाव-प्रकार के प्रश्न के बजाए इसे एक उचित प्रश्न बनाने के लिए थोड़ा सा सवाल उठाया। –

+0

मुझे रीडवर्ड करने में खुशी है मुझे यकीन नहीं है कि इसे फिर से क्या कहना है। –

उत्तर

34

यहां कुछ अच्छी टिप्पणियां हैं, लेकिन मुझे लगता है कि एक चीज़ को अनदेखा किया जा रहा है।

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

यह वास्तव में पहले चीज महसूस करता है, लेकिन यह देखने के लिए आश्चर्यजनक है कि आपकी आंखों के सामने चीजें सामने आती हैं जिन्हें आपने मूल रूप से नहीं सोचा था। मैंने इसे देखा है।

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

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

+0

आप यूनिट टेस्ट को पहले कैसे बनाते हैं? आईडीई बहुत सारी चेतावनी और त्रुटि पॉप करेगा और इंटेलिजेंस काम नहीं करेगा! मैं नहीं देखता कि यह कैसे करें। – Pokus

+0

आईडीई विधि स्टब उत्पन्न करने दें। सभी परीक्षण पहले विफल हो जाएंगे। – flukus

+0

@Pokus - त्वरित उत्तर है ... मैं ऑटो-स्टेटमेंट पूरा करना बंद कर देता हूं ताकि इंटेलिजेंस मेरे रास्ते में न हो। अगर मुझे इसकी ज़रूरत है तो CTRL + space हमेशा इसे लाएगा। मैं अत्यधिक रेसर्पर (http://jetbrains.com/resharper) की सिफारिश करता हूं। यह मेरे टीडीडी वर्कफ़्लो को भारी रूप से सहायता करता है। –

2

हमेशा नहीं, लेकिन मुझे लगता है कि यह वास्तव में मदद करता है जब मैं करता हूं।

2

मैं उन्हें लिखता हूं क्योंकि मैं अपना कोड लिखता हूं। अधिकतर मैं परीक्षण लिखूंगा कि कक्षा/मॉड्यूल लिखने से पहले मौजूद है या नहीं।

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

मुझे नहीं पता कि यह मेरी सोच या विधि या सिर्फ TIMTOWTDI में एक दोष है या नहीं।

+0

TIMTOWTD? ये क्या अजीब है? –

+1

ऐसा करने के एक से अधिक तरीके हैं। एक ही समय के बारे में कोड + टेस्ट परीक्षण-संचालित हो सकते हैं। कोड को खराब करें, अच्छे परीक्षण लिखें, कोड समाप्त करें। –

0

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

7

studies रहा है जो दिखाता है कि कोड लिखने के बाद लिखे गए यूनिट परीक्षण बेहतर परीक्षण हैं। हालांकि चेतावनी यह है कि लोग घटना के बाद उन्हें लिखने की आदत नहीं रखते हैं। इसलिए टीडीडी एक अच्छा समझौता है क्योंकि कम से कम परीक्षण लिखे जाते हैं।

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

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

+0

क्या आप अध्ययन के लिंक प्रदान कर सकते हैं? धन्यवाद – roundcrisis

+1

इस उत्तर का लिंक अध्ययन परिणामों पर सवाल पूछने वाले ब्लॉग पोस्ट को इंगित करता है, न कि विभिन्न परिणामों के साथ वास्तविक अध्ययनों के लिए। परिणामस्वरूप मैं इस उत्तर की पहली पंक्ति की वैधता छूट दूंगा। –

+1

लिंक अध्ययन टीम की निष्कर्षों के निष्कर्षों के विस्तृत विश्लेषण के लिए इंगित करता है और उनके निष्कर्ष गलत क्यों हैं। अध्ययन वास्तव में स्पष्ट रूप से दिखाता है कि परीक्षण के बाद परीक्षण पहले से बेहतर है (बस इतना ही लंबा है) –

2

मैं शुरू करता हूं कि मैं अपनी "इकाई" को कैसे कॉल करना चाहता हूं और इसे संकलित करना चाहता हूं। की तरह:

picker = Pick.new 
item=picker.pick('a') 
assert item 

तो मैं बनाने

class Pick 
def pick(something) 
return nil 
end 
end 

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

तो, संक्षेप में। हाँ। अनुपात से पहले परीक्षण कर यह नहीं कर रही की तुलना में बहुत अधिक है।

0

चरम प्रोग्रामिंग के साथ याद रखें आपके परीक्षण प्रभावी रूप से आप डॉक्यूमेनेशन हैं। इसलिए यदि आप नहीं जानते कि आप क्या परीक्षण कर रहे हैं, तो आप नहीं जानते कि आप क्या चाहते हैं कि आपका आवेदन करने जा रहा है?

आप "कहानियां" जो

की तरह कुछ हो सकता है के साथ शुरू कर सकते हैं

तब के रूप में आप इकाई परीक्षण हल करने के लिए कोड लिखना शुरू "उपयोगकर्ता सवालों की सूची प्राप्त कर सकते हैं"। उपरोक्त को हल करने के लिए आपको कम से कम एक उपयोगकर्ता और प्रश्न वर्ग की आवश्यकता होगी। तो फिर आप क्षेत्रों के बारे में सोचना शुरू कर सकते हैं:

आदि आशा है कि यह मदद करता है "उपयोगकर्ता वर्ग नाम जन्म तिथि पता TelNo बंद फील्ड्स है"।

Crafty

0

हाँ, अगर तुम सच TDD सिद्धांतों का उपयोग कर रहे हैं। अन्यथा, जब तक आप यूनिट-टेस्ट लिख रहे हों, आप सबसे ज्यादा बेहतर कर रहे हैं।

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

0

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

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

2

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

1

परीक्षण लेखन पहले अपने कोड की तरह दिखाई देगा कैसे परिभाषित करता है। यह आसान परीक्षण के लिए अलग-अलग तरीकों से सभी कोर कार्यक्षमता को अलग करने में भी मदद करता है।

6

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

तो अपने वोट है: टेस्ट पहले

पुनश्च: और नहीं, मतलब है कि यह नहीं है कि आप पहले अपने वास्तुकला की योजना की जरूरत नहीं है कि, लेकिन आप इसे पुनर्विचार सकता है कि अगर परीक्षण करने के लिए आपको बता ऐसा करो !!!!

2

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

यहां पर मेरा समझौता है और मैंने इसे काफी उपयोगी और उत्पादक पाया है।

आमतौर पर सही होने का सबसे कठिन हिस्सा आपकी कक्षा, एपीआई, पैकेज की उपयोगिता के पीछे की आवश्यकताएं और सही है ... फिर वास्तविक कार्यान्वयन है।

  1. अपने इंटरफेस लिखें (वे बदल जाएगा, लेकिन जानते हुए भी क्या किया जा सकता है में एक काफी मदद मिलेगी)
  2. इंटरफेस का उपयोग करने के लिए एक सरल कार्यक्रम लिखें (उन्हें बेवकूफ मुख्य)। यह का निर्धारण कैसे यह जा रहा है प्रयोग की जाने वाली इंटरफेस (बिट मैं TDD से एकीकृत पर (जैसा कि अक्सर रूप में की जरूरत वापस 1 करने के लिए जाना)
  3. लिखें परीक्षण, फिर से वापस 1 के रूप में अक्सर जाना करने में काफी मदद हो जाता है जरूरत के रूप में)
  4. इंटरफेस के पीछे वास्तविक कोड लिखने
  5. वर्गों पर
  6. लिखने परीक्षण और वास्तविक क्रियान्वयन, बनाने के लिए एक कवरेज उपकरण का उपयोग सुनिश्चित करें कि आप weid निष्पादन रास्तों

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

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

क्या यह कड़ाई से टीडीडी बोल रहा है? चरम? चुस्त...? जो कुछ... ? मुझे नहीं पता, और स्पष्ट रूप से मुझे परवाह नहीं है। यह मुझे के लिए काम करता है। मैं इसे समायोजित करने के रूप में समायोजित करता हूं और सॉफ्टवेयर विकास अभ्यास की मेरी समझ विकसित होती है।

मेरी 2 फीसदी

5

मैं पिछले 6-7 साल के लिए नेतृत्व विकास टीमों है। मैं निश्चित रूप से क्या कह सकता हूं कि एक डेवलपर और डेवलपर्स के साथ मैंने काम किया है, यह कोड की गुणवत्ता में एक असाधारण अंतर बनाता है अगर हम जानते हैं कि हमारा कोड बड़ी तस्वीर में कहाँ फिट बैठता है।

टेस्ट ड्राइव डेवलपमेंट (टीडीडी) हमें "क्या?" जवाब देने में मदद करता है इससे पहले कि हम जवाब दें "कैसे?" और यह एक बड़ा अंतर बनाता है।

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

1

व्यक्तिगत रूप से, मेरा मानना ​​है कि इकाई परीक्षण उनके प्रभाव का एक बहुत कुछ खो देते हैं तो कोड लिखने से पहले नहीं किया। परीक्षण के साथ

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

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

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

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

2

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

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

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

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

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

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

0

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

1

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

1

मुझे यकीन है कि नहीं कर रहा हूँ, लेकिन अपने वर्णन से मैं समझ है कि वहाँ क्या परीक्षण पहले वास्तव में इसका मतलब है पर एक गलतफहमी हो सकती है। यह का अर्थ है कि आप सभी लिखते हैं तो पहले आपके परीक्षण। इसका मतलब यह आप की

  1. एक भी, कम से कम परीक्षण
  2. न्यूनतम उत्पादन कोड आवश्यक
  3. अगले परीक्षण लिखने लिख कर परीक्षण पास कर लिखना एक बहुत तंग चक्र है कि है कि असफल हो जायेगी
  4. मौजूदा उत्पादन कोड को सबसे आसान संभव तरीके से बदलकर
  5. कोड (दोनों परीक्षण और उत्पादन!) को दोबारा दोहराएं ताकि इसमें डुप्लिकेशन हो और अभिव्यक्तिपूर्ण
  6. जारी रखें 3. जब तक आप एक और समझदार परीक्षण

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

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

ओह, और यह नहीं लग रहा है "प्राकृतिक" के बारे में, यह क्या आप के लिए उपयोग किया जाता है की बस एक बात है। मैं उन लोगों को जानता हूं जो हर दो मिनट में एक हरे रंग की बार (सामान्य एक्सयूनीट साइन "सभी परीक्षण पास करने" के लिए आम तौर पर आदी हैं)।

1

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

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

सबसे ridicoulous बात अगर वे बहस करने शुरू "मैं इस परीक्षण के बारे में पहली बात यह है conviced नहीं कर रहा हूँ लेकिन मैं इसे इस तरह से कभी नहीं किया है" ...महान ...

मुझे आश्चर्य है कि इकाई परीक्षण मूल रूप से कहां से आता है। क्योंकि अगर अवधारणा वास्तव में टीडीडी से निकलती है तो यह सिर्फ हास्यास्पद है कि लोगों को यह कैसे गलत लगता है।

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