मेरे पास अभी के लिए एक प्रासंगिक किस्सा है जो अभी मेरे लिए चल रहा है। मैं एक ऐसी परियोजना पर हूं जो टीडीडी का उपयोग नहीं करता है। हमारे क्यूए लोग हमें उस दिशा में आगे बढ़ा रहे हैं, लेकिन हम एक छोटे संगठन हैं और यह एक लंबी, खींची गई प्रक्रिया है।
वैसे भी , मैं हाल ही में एक विशिष्ट कार्य करने के लिए तीसरे पक्ष के पुस्तकालय का उपयोग कर रहा था। उस पुस्तकालय के उपयोग के संबंध में एक समस्या थी, इसलिए मुझे अनिवार्य रूप से उसी पुस्तकालय के एक संस्करण को लिखने के लिए मुझ पर डाल दिया गया। कुल मिलाकर, यह निष्पादन योग्य कोड की लगभग 5,000 पंक्तियों और मेरे समय के लगभग 2 महीनों में समाप्त हो गया। मुझे पता है कि कोड की लाइनें एक खराब मीट्रिक है, लेकिन इस उत्तर के लिए मुझे लगता है कि यह परिमाण का एक अच्छा संकेतक है।
एक विशेष डेटा संरचना थी जिसकी मुझे आवश्यकता थी जो मुझे बिट्स की एक मनमानी संख्या पर नज़र रखने की अनुमति देगा। चूंकि परियोजना जावा में है, इसलिए मैंने जावा को चुना BitSetऔर इसे थोड़ा संशोधित किया (मुझे अग्रणी 0एस को ट्रैक करने की क्षमता की आवश्यकता थी , जो कि जावा का बिटसेट किसी कारण से नहीं करता है .....)। ~ 93% कवरेज तक पहुंचने के बाद मैंने कुछ परीक्षण लिखना शुरू किया जो वास्तव में मेरे द्वारा लिखी गई प्रणाली पर जोर देगा। मुझे यह सुनिश्चित करने के लिए कार्यक्षमता के कुछ पहलुओं को बेंचमार्क करने की आवश्यकता थी कि वे मेरी अंतिम आवश्यकताओं के लिए पर्याप्त तेज़ होंगे। अप्रत्याशित रूप से, BitSetइंटरफ़ेस से मैंने जिन कार्यों को ओवरराइड किया था, उनमें से एक बड़े बिट सेट्स (इस मामले में लाखों बिट्स के सैकड़ों) के साथ काम करते समय बेतुका धीमा था। अन्य ओवरराइड किए गए फ़ंक्शंस इस एक फ़ंक्शन पर निर्भर थे, इसलिए यह एक बड़ी बोतल गर्दन थी।
मैंने जो किया, वह ड्राइंग बोर्ड में जा रहा था, और अंतर्निहित संरचना में हेरफेर करने का एक तरीका पता लगा रहा था BitSet, जो कि ए long[]। मैंने एल्गोरिथ्म को डिज़ाइन किया, उनके इनपुट के लिए सहयोगियों से पूछा, और फिर मैंने कोड लिखने के बारे में सेट किया। फिर, मैंने यूनिट परीक्षणों को चलाया। उनमें से कुछ टूट गए, और जिन लोगों ने मुझे ठीक करने के लिए मुझे अपने एल्गोरिथ्म में देखने की आवश्यकता थी, ठीक उसी ओर इशारा किया। यूनिट परीक्षणों से सभी त्रुटियों को ठीक करने के बाद, मैं यह कहने में सक्षम था कि फ़ंक्शन उसी तरह काम करता है जैसा कि इसे करना चाहिए। बहुत कम से कम, मुझे विश्वास हो सकता है कि इस नए एल्गोरिथ्म ने पिछले एल्गोरिथम के साथ-साथ काम किया।
बेशक, यह बुलेट प्रूफ नहीं है। अगर मेरे कोड में एक बग है जिसे यूनिट परीक्षण के लिए जाँच नहीं कर रहा है, तो मुझे यह पता नहीं चलेगा। लेकिन निश्चित रूप से, यह वही बग मेरे धीमी एल्गोरिथ्म में भी हो सकता था। हालांकि , मैं विश्वास के उच्च स्तर के साथ कह सकता हूं कि मुझे उस विशेष फ़ंक्शन से गलत आउटपुट के बारे में चिंता करने की आवश्यकता नहीं है। पहले से मौजूद इकाई परीक्षणों ने मुझे सही करने के लिए नए एल्गोरिथ्म का परीक्षण करने के प्रयास के घंटों, शायद दिनों की बचत की।
टीडीडी की परवाह किए बिना यूनिट टेस्ट होने की बात यह है - कहने का मतलब यह है कि यूनिट टेस्ट आपको टीडीडी में और टीडीडी के बाहर सभी के लिए एक समान करेगा, जब आप कोड को रीफैक्टरिंग / मेंटेन करते हैं। बेशक, इसे नियमित प्रतिगमन परीक्षण, धुआं परीक्षण, फजी परीक्षण, आदि के साथ जोड़ा जाना चाहिए, लेकिन इकाई परीक्षण, जैसा कि नाम बताता है, सबसे छोटी, परमाणु स्तर पर चीजों का परीक्षण करता है, जो आपको दिशा देता है जहां त्रुटियां पॉप अप हुई हैं।
मेरे मामले में, मौजूदा यूनिट परीक्षणों के बिना, मुझे किसी भी समय एल्गोरिथम को सुनिश्चित करने की एक विधि के साथ आना होगा। जो, अंत में ... इकाई परीक्षण की तरह लगता है , है ना?