बढ़ती टेस्टेबिलिटी, डेल्फी फ्रेमवर्क के लिए बोल्ड के साथ कोडिंग करते समय

Question

पृष्ठभूमि मैं 7 डेवलपर्स और 2 परीक्षकों की एक टीम में काम करता हूं जो रसद प्रणाली पर काम करते हैं। हम ढांचे के रूप में Bold for Delphi के साथ डेल्फी 2007 और मॉडेलरीवन विकास का उपयोग करते हैं। सिस्टम लगभग 7 वर्षों में उत्पादन में रहा है और इसमें लगभग 1,7 मिलियन लाइन कोड हैं। हम 4-5 सप्ताह के बाद उत्पादन में रिलीज करते हैं और लगभग हर रिलीज के बाद हमें उन बगों के लिए कुछ पैच करना पड़ता है जिन्हें हम नहीं पाते हैं। यह निश्चित रूप से हमारे और ग्राहकों दोनों के लिए परेशान है।

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

इकाई परीक्षण पूर्व शर्त मुझे लगता है कि मैं इकाई परीक्षण के लिए कुछ पूर्व शर्त पता:

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

फ्रेमवर्क का उपयोग करने के हम मुख्य रूप से 64-बिट संकलक की वजह से डेल्फी XE2 में नवीनीकृत कर सकते हैं। मैंने Spring को थोड़ा सा देखा है लेकिन इसके लिए डी 2007 से अपडेट की आवश्यकता है और यह अब नहीं होगा। शायद अगले वर्ष।

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

संपादित करें: मैन्युअल परीक्षण के लिए वर्तमान परीक्षण पद्धति के बारे में केवल "इसे पाउंड करें और इसे तोड़ने का प्रयास करें" Chris इसे कॉल करें।

Answer 1

आप माइकल फेदर्स, Working Effectively with Legacy Code द्वारा पुस्तक चाहते हैं। यह दिखाता है कि कैसे कोड (इकाई) परीक्षण को कोड में पेश करना है जो दिमाग में टेस्टेबिलिटी के साथ नहीं लिखा गया था।

अध्यायों बहाने के लिए नाम हैं में से कुछ एक डेवलपर क्यों पुराने कोड का परीक्षण मुश्किल है के लिए दे सकता है, और वे मामले के अध्ययन होते हैं और प्रत्येक समस्या का समाधान करने के लिए तरीके का सुझाव दिया:

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

यह निर्भरताओं को तोड़ने के लिए कई तकनीकों को भी शामिल करता है; कुछ आपके लिए नए हो सकते हैं, और कुछ आप पहले से ही जानते हैं लेकिन अभी तक उपयोग करने के लिए सोचा नहीं है।

Answer 2

आपकी परीक्षण टीम बहुत छोटी है, आईएमओ। मैंने टीमों में काम किया है जहां क्यूए विभाग ने डेवलपर्स को पीछे छोड़ दिया है। छोटे चक्रों में फिट होने वाले प्रबंधनीय हिस्सों (विशेषताओं, फिक्स) के "स्पिंट्स" में काम करने पर विचार करें। "Agile" 2 सप्ताह के स्पिंट को प्रोत्साहित करेगा, लेकिन यह बहुत तंग हो सकता है। वैसे भी, यह क्यूए लगातार जारी रखेगा, रिलीज विंडो से आगे काम कर रहा है। अभी, मुझे संदेह है कि जब तक आप उन्हें बड़ी संख्या में कोड नहीं देते हैं, तब तक वे निष्क्रिय होते हैं, फिर वे दलदल हो जाते हैं। छोटे रिलीज चक्र के साथ, आप अधिक परीक्षकों को व्यस्त रख सकते हैं।

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

आईएमओ, डाटािट, संचार इत्यादि जैसी कई निर्भरताओं के साथ ड्यूनिट परीक्षण करना मुश्किल है .. लेकिन यह करने में सक्षम है। मैंने DUnit कक्षाएं बनाई हैं जो स्वचालित रूप से डेटाबेस सेटअप स्क्रिप्ट चलाती हैं (कक्षा के परीक्षण के रूप में एक ही नाम के साथ एक .sql फ़ाइल की तलाश करें, एसक्यूएल चलाएं, फिर परीक्षण आय), और यह बहुत प्रभावी रहा है। एसओएपी संचार के लिए, मेरे पास एक सोपूआई मोज़ेक चल रहा है जो डिब्बाबंद परिणाम देता है, इसलिए मैं अपने संचार का परीक्षण कर सकता हूं।
यह काम करता है, लेकिन यह इसके लायक है।

Answer 3

स्वचालित इकाई परीक्षण के लिए आवश्यकताओं को वास्तव में इस प्रकार हैं:

1. एक इकाई परीक्षण ढांचे (उदाहरण के लिए, DUnit) का उपयोग करें।
2. किसी प्रकार का मॉकिंग फ्रेमवर्क का उपयोग करें।

आइटम 2 कठिन है।

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

रिलीज में बदले गए सामान और सामानों के लिए परीक्षण लिखने पर विचार करें। समय के साथ आप इकाई परीक्षण का उचित आधार प्राप्त करेंगे। नई और बदली गई सामग्री को भी दोबारा प्रतिक्रिया दी जा सकती है (या अच्छी तरह से लिखा गया है)।

इसके अलावा, एक स्वचालित निर्माण प्रक्रिया पर विचार करें जो यूनिट परीक्षण चलाता है और बिल्ड ब्रेक होने पर ईमेल भेजता है।

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