बहुत तंग समय सीमा के कारण विकास के दौरान कोई परीक्षण-संचालित विकास प्रक्रिया नहीं थी
यह कथन बहुत ही संबंधित है। इसलिए नहीं कि इसका मतलब है कि आप टीडीडी के बिना विकसित हुए हैं या क्योंकि आप हर चीज का परीक्षण नहीं कर रहे हैं। यह संबंधित है, क्योंकि यह दिखाता है कि आपको लगता है कि टीडीडी आपको धीमा कर देगा और आपको एक समय सीमा याद कर देगा।
जब तक आप इसे इस तरह से देखते हैं, आप टीडीडी के लिए तैयार नहीं हैं। TDD कुछ ऐसा नहीं है जिसे आप धीरे-धीरे कम कर सकते हैं। आप या तो जानते हैं कि यह कैसे करना है या आप नहीं करते हैं। यदि आप इसे आधा करने की कोशिश करते हैं तो आप इसे बनाने जा रहे हैं और अपने आप को खराब दिखते हैं।
टीडीडी एक ऐसी चीज है जिसे आपको पहले घर पर अभ्यास करना चाहिए। इसे करना सीखें, क्योंकि यह अब आपको कोड करने में मदद करता है । इसलिए नहीं कि किसी ने आपको ऐसा करने के लिए कहा था। इसलिए नहीं कि जब आप बाद में बदलाव करेंगे तो यह मदद करेगा। जब यह कुछ ऐसा हो जाता है जो आप कर रहे हैं क्योंकि आप जल्दी में हैं तो आप इसे पेशेवर रूप से करने के लिए तैयार हैं।
टीडीडी एक ऐसी चीज है जिसे आप किसी भी दुकान में कर सकते हैं । आपको अपने परीक्षण कोड को भी चालू नहीं करना है। यदि आप दूसरों का परीक्षण तिरस्कार करते हैं तो आप इसे अपने पास रख सकते हैं। जब आप इसे सही करते हैं, तो परीक्षण आपके विकास को गति देते हैं, भले ही कोई और उन्हें न चलाता हो।
दूसरी ओर यदि अन्य लोग आपके परीक्षणों को पसंद करते हैं और चलाते हैं, तब भी आपको यह ध्यान रखना चाहिए कि टीडीडी की दुकान में भी परीक्षणों में जाँच करना आपका काम नहीं है। यह साबित काम उत्पादन कोड बनाने के लिए है। यदि ऐसा होता है तो परीक्षण योग्य, साफ-सुथरा।
अगर आपको लगता है कि प्रबंधन को टीडीडी पर विश्वास करना है या आपके साथी कोडर्स को आपके परीक्षणों का समर्थन करना है तो आप टीडीडी आपके लिए सबसे अच्छी बात की अनदेखी कर रहे हैं। यह आपको जल्दी से यह बताता है कि आप क्या सोचते हैं कि आपका कोड क्या करता है और यह वास्तव में क्या करता है।
यदि आप यह नहीं देख सकते हैं कि कैसे, अपने दम पर, आप तेजी से समय सीमा को पूरा करने में मदद कर सकते हैं तो आप काम में TDD के लिए तैयार नहीं हैं। आपको घर पर अभ्यास करने की आवश्यकता है।
उस ने कहा, यह अच्छा है जब टीम आपके उत्पादन कोड को पढ़ने में मदद करने के लिए आपके परीक्षणों का उपयोग कर सकती है और जब प्रबंधन spiffy नए TDD उपकरण खरीदेगा।
क्या टीम को TDD में बदलने के बाद सभी संभावित परीक्षण मामलों को लिखना एक अच्छा विचार है?
भले ही टीम जो कर रही है वह हमेशा सभी संभावित परीक्षण मामलों को लिखने के लिए एक अच्छा विचार नहीं है। सबसे उपयोगी परीक्षण मामलों को लिखें। 100% कोड कवरेज लागत पर आता है। निर्णय कम करने के नियम को अनदेखा न करें क्योंकि निर्णय लेना कठिन है।
दिलचस्प व्यावसायिक तर्क के लिए अपनी परीक्षण ऊर्जा को बचाएं। वह सामान जो निर्णय लेता है और नीति को लागू करता है। उस में से बिल्ली का परीक्षण करें। बोरिंग स्पष्ट रूप से आसानी से पढ़ा जाने वाला संरचनात्मक गोंद कोड जो केवल तारों के सामान को एक साथ रखता है, लगभग उतनी बुरी तरह से परीक्षण की आवश्यकता नहीं है।
(1) क्या यह अभी भी ठीक है या अधिकांश विकास को रोकने के लिए अच्छा विचार है और शुरू से ही पूरे संभव परीक्षण मामलों को लिखना शुरू कर दिया है, भले ही सब कुछ पूरी तरह से ठीक हो रहा हो (अभी तक!)। या
नहीं। यह "पूरी तरह से फिर से लिखना" सोच है। इससे कठिन जीता हुआ ज्ञान नष्ट हो जाता है। परीक्षण लिखने के लिए प्रबंधन से समय न मांगें। बस टेस्ट लिखो। एक बार जब आप जानते हैं कि आपका क्या करना है, तो परीक्षण आपको धीमा नहीं करेंगे।
(2) कुछ बुरा होने की प्रतीक्षा करना बेहतर है और फिर फिक्स के दौरान नई इकाई परीक्षण लिखें, या
(3) यहां तक कि पिछले कोड के बारे में भूल जाते हैं और केवल नए कोड के लिए यूनिट टेस्ट लिखते हैं और अगले प्रमुख रिफ्लेक्टर के लिए सब कुछ स्थगित करते हैं।
मैं उसी तरह से 2 और 3 का जवाब दूंगा। जब आप किसी भी कारण से कोड बदलते हैं, तो यह वास्तव में अच्छा है यदि आप किसी परीक्षा में फिसल सकते हैं। यदि कोड विरासत है तो यह वर्तमान में एक परीक्षण का स्वागत नहीं करता है। इसका मतलब है कि इसे बदलने से पहले इसका परीक्षण करना कठिन है। खैर, चूंकि आप इसे बदल रहे हैं, वैसे भी आप इसे किसी परीक्षण योग्य चीज में बदल सकते हैं और इसका परीक्षण कर सकते हैं।
वह परमाणु विकल्प है। यह जोखिम भरा है। आप परीक्षण के बिना परिवर्तन कर रहे हैं। परिवर्तन करने से पहले विरासत कोड को परीक्षण के तहत रखने के लिए कुछ रचनात्मक तरकीबें हैं। आप उस सीम को कहते हैं जो आपको कोड को बदले बिना आपके कोड के व्यवहार को बदलने की अनुमति देता है। आप कॉन्फ़िगरेशन फ़ाइलों को बदलते हैं, फ़ाइलों का निर्माण करते हैं, जो कुछ भी इसे लेता है।
माइकल फेयर्स ने हमें इस बारे में एक पुस्तक दी: वर्किंग इफेक्टिवली विथ लेगेसी कोड । इसे पढ़ें, और आप देखेंगे कि आपको कुछ नया करने के लिए पुराने सब कुछ को जलाने की ज़रूरत नहीं है।