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