इकाई परीक्षण प्रक्रियात्मक कोड प्रभावी है?

Question

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

इसलिए संक्षेप में मेरा प्रश्न यह है कि क्या हमारे वर्तमान कोडबेस के साथ इकाई परीक्षण के लिए आगे बढ़ना बुद्धिमानी होगी, या यह सुझाव देना होगा कि इसे तब तक के लिए स्थगित कर दिया जाए जब तक कि आवेदन को उचित OOP ढांचे में स्थानांतरित न कर दिया गया हो?

पुनश्च: जबकि मैंने इस प्रश्न को भाषा अज्ञेय के रूप में शैली देने की कोशिश की है, मुझे लगता है कि प्रश्न में एप्लिकेशन को बताते हुए PHP और जावास्क्रिप्ट का उपयोग करने में अधिक विशिष्ट उत्तर देने में मदद मिलेगी जो इस प्रश्न का उत्तर दे सकता है क्योंकि अनुभव से यह घटना ऐसे अनुप्रयोगों के साथ होती है।

Comments

यूनिट परीक्षण नए बग को रोकता नहीं है, यह प्रतिगमन को रोकता है।

— 12:07

लीगेसी कोड के साथ काम करने पर यूनिट टेस्ट जनरेटर के संभावित डुप्लिकेट ने आपकी मदद की? और एक दर्जन अन्य प्रश्न। "विरासत इकाई परीक्षण" के लिए खोजें

— मैट्नज़

आपकी समस्या यह है कि कोड स्पेगेटी / बिग बॉल ऑफ मड है, यह नहीं कि यह "प्रक्रियात्मक" है (अच्छा प्रक्रियात्मक कोड केवल ठीक है - बीटीडीटीजीटीएस)। आपकी शक्तियाँ बल्कि (अधिक) परीक्षक प्राप्त करेंगी और परियोजना में पूरी तरह से पेशेवर गुणवत्ता आश्वासन की व्यवस्था करेंगी यदि वे "बग की निरंतर मात्रा से बचना चाहते हैं"।

— कुटकी

@ l0b0 हां मैंने किया। मेरी क्षमायाचना, परीक्षण को स्पष्ट करने के लिए अपडेट करेगी

— कनाडा की यात्रा

@ मट्टनज़ हां मैंने प्रक्रियात्मक इकाई परीक्षण के लिए खोज की, लेकिन विरासत नहीं। कि प्रक्रियात्मक लगा = विरासत वहाँ अभी भी नए कोड उस प्रारूप में बनाया जा रहा है, क्योंकि!

— canadiancreed

Answer 1

यूनिट परीक्षण वस्तुओं के साथ अच्छी तरह से काम करता है, खासकर जब से यह मॉक ऑब्जेक्ट्स की तरह बहुत सारी फैंसी सुविधाएँ प्रदान करता है, जो बेहतर परीक्षण तेजी से बनाने में मदद करता है।

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

ध्यान दें कि आपको निम्न करना होगा:

• उन कार्यों को अलग करें जिन्हें आपको परीक्षण करना है और जिन्हें आपको करने की आवश्यकता नहीं है। OOP में, यह आसान है: निजी तरीकों का परीक्षण नहीं करना पड़ता है क्योंकि कॉल करने वाले कभी भी सीधे उन तक नहीं पहुंच पाएंगे। संभावना है, आपके प्रक्रियात्मक कोड में, कुछ कार्य इस तरह हैं और परीक्षणों की आवश्यकता नहीं है।

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

• बाहर के कार्यों के साथ कोड से निपटें। यह अधिक जटिल मामला है, लेकिन फिर भी संभव है। या तो आप require_onceयह देखने के लिए पृष्ठ बनाते हैं कि क्या होता है और / के माध्यम से आउटपुट को पकड़ता हैob_startob_get_clean , या आप परीक्षण सूट से HTTP अनुरोध करते हैं और HTML को पार्स करके प्रतिक्रिया का विश्लेषण करते हैं। यह वास्तव में एक यूआई परीक्षण नहीं है: यहां, आप परवाह नहीं करते हैं कि पृष्ठ पर एक बटन बाईं तरफ या दाईं ओर दिखाई देता है या यदि एक लिंक बड़े लाल कैपिटल अक्षरों में या छोटे नीले वाले में है। डोम के माध्यम से कुछ HTML तत्वों को खोजने और उनकी सामग्री की अपेक्षा की तुलना करने के लिए आपको क्या परवाह है ।

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

Answer 2

सुझाव दें कि इसे तब तक के लिए स्थगित कर दिया जाए जब तक कि आवेदन एक उचित ओओपी ढांचे में स्थानांतरित न हो जाए

किसी अन्य प्लेटफ़ॉर्म पर माइग्रेट करने से पहले कुछ स्वचालित परीक्षण करें , बाद में नहीं। माइग्रेशन करते समय आगे के परीक्षण जोड़ें, न कि बाद में। यदि वे परीक्षण "एकीकरण परीक्षण" या इकाई परीक्षण हैं जिन्हें आपको स्वयं तय करना है, लेकिन आमतौर पर आप अपने पसंदीदा xUnit परीक्षण ढांचे का उपयोग दोनों प्रकार से कर सकते हैं।

Answer 3

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

उन परीक्षणों को कैसे लागू किया जाता है, यह प्रतिमानों और भाषाओं के बीच भिन्न होगा। यूनिट परीक्षण करने की आपकी क्षमता को प्रभावित करने वाली सबसे बड़ी चीजें कोड की गुणवत्ता है; कम तो प्रतिमान का इस्तेमाल किया। याद रखें इकाई परीक्षण अलगाव में कोड की "इकाई" के परीक्षण के बारे में है। कुछ भी जो कोड की "इकाइयों" को अलग करने की आपकी क्षमता को प्रभावित करता है, परीक्षण को कठिन बना देगा।

• ग्लोबल्स का उपयोग
• दुष्प्रभाव
• कसकर युग्मित कोड
• बुरी तरह से युग्मित कोड
• सशर्त की एक बड़ी संख्या
• बुरी तरह से डिज़ाइन की गई "इकाइयाँ"

इन सभी का भाषा प्रतिमान की तुलना में परीक्षण की कठिनाई पर अधिक प्रभाव पड़ेगा।

Answer 4

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

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

Answer 5

मुझे नहीं लगता कि प्रक्रियात्मक कोड के खिलाफ सही इकाई परीक्षण करना संभव है। मुख्य समस्या यह है कि प्रत्येक प्रक्रिया में कई निर्भरताएँ होंगी, जिन्हें बाहर नहीं किया जा सकता है। सर्वोत्तम परीक्षणों में एकीकरण परीक्षण होंगे। मैंने MS Access में VB6 मॉड्यूल और VBA मॉड्यूल के साथ कई चन्द्रमाओं के समान काम किया है।

उस ने कहा, अगर आप सबसे अधिक दर्द पैदा करने वाले तरीकों के इर्द-गिर्द टेस्ट मचान रख सकते हैं, तो यह सही है?

Comments

-1: खराब डिजाइन और कार्यान्वयन समस्या है, प्रक्रियात्मक कोड नहीं। जैसे आप भयानक ओपी लिख सकते हैं, वैसे ही आप शानदार प्रक्रियात्मक कोड लिख सकते हैं।

— मटनज

@mattnz - मुझे यकीन नहीं है कि आपकी टिप्पणी इकाई परीक्षण प्रक्रियात्मक कोड के बारे में क्या कहती है, या होने में सक्षम नहीं है।

— रोब ग्रे

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

— मार्जन वेनमा

एक अच्छा डिजाइन किसी भी कोड, प्रक्रियात्मक या नहीं में इकाई-परीक्षणीयता का परिचय देता है।

— डॉक ब्राउन