मैं उन लोगों के बारे में पढ़ता रहता हूं जो "परीक्षण संक्रमित" हैं, जिसका अर्थ है कि वे सिर्फ टीडीडी नहीं प्राप्त करते हैं बल्कि इसके बिना भी नहीं रह सकते हैं। उनके पास "बदलाव था" जैसा था। सवाल यह है कि, मैं ऐसा कैसे प्राप्त करूं?मैं टीडीडी के साथ "संक्रमित परीक्षण" कैसे बनूं?
"संक्रमित परीक्षण" होने के बिंदु का हिस्सा यह है कि आपने टीडीडी का पर्याप्त उपयोग किया है और सफलताओं को पर्याप्त देखा है आप इसके बिना कोड नहीं चाहते हैं। एक बार जब आप पहले लेखन परीक्षणों के चक्र से गुज़र चुके हैं, तो कोडिंग और रीफैक्टरिंग और आपकी बग गिनती को देखते हुए परिणामस्वरूप आपका कोड बेहतर हो जाता है, न केवल यह दूसरी प्रकृति बनता है जैसे ज़ेक्सॉस ने कहा, आपको कठिन समय है पहले कोड पर वापस। यह परीक्षण संक्रमित किया जा रहा है।
प्रारंभ करने के लिए टीडीडी के बारे में जानें, और उसके बाद इसे अपने वर्कफ़्लो में एकीकृत करना प्रारंभ करें। यदि आप पर्याप्त पद्धतियों का उपयोग करते हैं, तो आप पाएंगे कि वे दूसरी प्रकृति बन गए हैं और आप उस ढांचे के भीतर अपने सभी विकास कार्यों को तैयार करना शुरू कर देंगे।
इसके अलावा, अपनी पसंद की भाषा के लिए जे-यूनिट (या एक्स-यूनिट) ढांचे का उपयोग शुरू करें।
आप पहले ही टीडीडी के बारे में पढ़ चुके हैं; और अधिक पढ़ने के लिए आपको उत्साहित नहीं किया जा रहा है।
इसके बजाय, आपको एक वास्तविक व्यक्तिगत सफलता की कहानी की आवश्यकता है।
यहां बताया गया है। कोर मॉड्यूल से कुछ कोड प्राप्त करें, कोड जो बाहरी सिस्टम या कई अन्य सबराउटिन पर निर्भर नहीं है। इससे कोई फर्क नहीं पड़ता कि नियमित कितना जटिल या सरल है।
फिर इसके खिलाफ यूनिट परीक्षण लिखना शुरू करें। (मुझे लगता है कि आपके पास xUnit या आपकी भाषा के लिए समान है।) परीक्षणों के साथ वास्तव में अप्रिय रहें - प्रत्येक सीमा मामले का परीक्षण करें, अधिकतम-int और min-int परीक्षण करें, परीक्षण नल, टेस्ट स्ट्रिंग्स और लाखों तत्वों के साथ सूचियां, कोरियाई और नियंत्रण पात्रों के साथ परीक्षण तार और दाएं से बाएं अरबी और उद्धरण और बैकस्लाश और अवधि और अन्य चीजें जो बचने से बचती हैं तो चीजें तोड़ती हैं।
आपको क्या मिलेगा .... बग! सबसे पहले आपको लगता है कि ये बग महत्वपूर्ण नहीं हैं - आपने अभी तक इन समस्याओं में भाग नहीं लिया है, आपका कोड शायद यह कभी नहीं करेगा, आदि। लेकिन मेरा अनुभव यह है कि यदि आप आगे बढ़ते रहते हैं तो आप चकित होंगे छोटी समस्याओं की संख्या पर। आखिरकार यह मानना मुश्किल हो जाता है कि इन बगों में से कोई भी कभी भी समस्या का कारण बन जाएगा।
प्लस आपको कुछ हासिल करने के साथ वास्तव में अच्छी तरह से किया जाता है, वास्तव में अच्छी तरह से किया जाता है। हम जानते हैं कि कोड कभी भी सही नहीं होता है और शायद ही कभी बग से मुक्त होता है, इसलिए यह अच्छा होता है जब हमने इतने सारे परीक्षण समाप्त कर दिए हैं कि हम वास्तव में आत्मविश्वास महसूस करते हैं। विश्वास एक अच्छी भावना है।
अंत में, मुझे लगता है कि आखिरी घटना जो प्यार को ट्रिगर करेगी सप्ताह या महीने बाद होगी। हो सकता है कि आप एक बग फिक्स कर रहे हों या एक फीचर जोड़ रहे हों या कुछ कोड रीफैक्टर कर रहे हों, और जो कुछ आप करते हैं वह यूनिट टेस्ट तोड़ देगा। "ओह?" आप कहेंगे, समझ में नहीं आया कि नया परिवर्तन टूटा परीक्षण के लिए भी प्रासंगिक क्यों था। फिर आप इसे पा सकते हैं, और ज्ञान प्राप्त कर सकते हैं। क्योंकि आप वास्तव में नहीं जानते थे कि आप कोड तोड़ रहे थे, और परीक्षणों ने आपको बचाया।
हेललुजाह!
एक शब्द, अभ्यास! टीडीडी करने के साथ कुछ ओवरहेड है और इसे दूर करने का तरीका अभ्यास करना और सुनिश्चित करना है कि आप प्रक्रिया की सहायता के लिए टूल का उपयोग कर रहे हैं। आपको अपने हाथ की पीठ की तरह टूल्स सीखना होगा। एक बार जब आप सीख रहे प्रक्रिया के साथ जाने के लिए टूल सीखते हैं, तो यह क्लिक करेगा और कोड को फ्लश करने के लिए पहले आप लेखन परीक्षणों के साथ धाराप्रवाह होंगे। फिर आप "संक्रमित परीक्षण" होंगे।
I answered कुछ समय पहले इसी तरह के प्रश्न। आप इसे भी देखना चाह सकते हैं। मैं कुछ औजारों का उल्लेख करता हूं और टीडीडी सीखने की व्याख्या करता हूं। इन उपकरणों में से, रिशेर्पर और टीडीडी करने के लिए एक अच्छा मॉकिंग फ्रेमवर्क चुनना महत्वपूर्ण है। मैं उन उपकरणों को सीखने पर दबाव नहीं डाल सकता जो आप परीक्षण फ्रेमवर्क के साथ पर्याप्त रूप से उपयोग कर रहे हैं।