टीडीडी करते समय आप अनुशासन को कैसे बनाए रखते हैं?

Question

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

कौन सी विधि (या सोचने या दिमाग की चाल या आत्म-इनाम नीति या जो कुछ भी) आप मदद के लिए उपयोग करते हैं अनुशासन बनाए रखें? या क्या आप इसे तब तक अभ्यास करते हैं जब तक यह प्राकृतिक महसूस न हो जाए?

Answer 1

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

मैं काम कर रहा टेस्ट प्रथम क्योंकि मुझे लगता है कि यह क्या कोड वास्तव में के रूप में एक संभवतः गलत मानसिक मॉडल के आधार पर अनुमान लगाने के लिए विरोध कर रहा है के साथ और अधिक मुझे रहता है धुन में अच्छा लगता है। मेरी धारणाओं की पुष्टि करने में सक्षम होने के कारण यह मेरे लिए एक बड़ा भुगतान है।

Answer 2

wear a green wristband

Answer 3

1) आप अपनी टीम में किसी और के साथ जोड़ी। एक व्यक्ति परीक्षण, अन्य उपकरण लिखता है।

इसे "पिंग-पोंग" जोड़ी कहा जाता है।

ऐसा करने से आप डिज़ाइन पर चर्चा करने और काम करने के लिए मजबूर होंगे।

इस चर्चा के बाद भी आसान क्या परीक्षण आप की जरूरत करने जा रहे हैं देखने के लिए बनाता है।

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

इन छोटी, आत्म निहित throwaway प्रयोगों आमतौर पर कर रहे हैं:

• एक त्वरित एक कार्यान्वयन की व्यवहार्यता स्थापित करने के लिए जिस तरह से, और
• अच्छी जगह एक परीक्षण में औपचारिकता शुरू करने के लिए।

Answer 4

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

Answer 5

जब मैं काम करता हूं तो मुझे आपको बताएगा कि मैं आपको बता दूंगा। :-)

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

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

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

Answer 6

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

यदि कोई परीक्षण जोड़ना है तो आपको पहले एक टेस्ट प्रोजेक्ट बनाना होगा, फिर काम करना अलग करें, घटकों को अलग करने के लिए, चीजों को नकली करने के लिए, आदि, यह बहुत मुश्किल टोकरी में है।

तो मुझे लगता है कि यह यूनिट परीक्षण पूरी तरह से आपकी विकास प्रक्रिया में एकीकृत होने के लिए वापस आता है।

Answer 7

जब मैंने पहली बार 2000 के आसपास टीडीडी करना शुरू किया, तो यह बहुत ही अप्राकृतिक महसूस हुआ। फिर एननेट के जेनेट और ज्यूनिट पोर्ट का पहला संस्करण आया, और मैंने शू स्तर (Shu-Ha-Ri) पर टीडीडी का अभ्यास शुरू किया, जिसका मतलब परीक्षण (पहले) सबकुछ था, जैसा कि आपके प्रश्नों के साथ था।

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

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

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

Answer 8

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

इसके अलावा, राज्य-आधारित परीक्षण के बजाय बातचीत या व्यवहार परीक्षण पर ध्यान केंद्रित करने का प्रयास करें।