कोड के लिए परीक्षण लिखना जिसका उद्देश्य मुझे समझ में नहीं आता है

Question

मैंने हाल ही में एक ब्लैक-बॉक्स रिफैक्टरिंग को पूरा किया। मैं इसे जांचने में असमर्थ हूं, क्योंकि मैं यह जांचने के लिए काम नहीं कर सकता हूं।

एक उच्च स्तर पर, मेरे पास एक वर्ग है जिसके आरंभ में कुछ वर्ग बी से मानों को हथियाना शामिल है। यदि वर्ग बी "खाली" है, तो यह कुछ समझदार चूक उत्पन्न करता है। मैंने इस भाग को एक विधि में निकाला, जो कक्षा बी को उन्हीं डिफॉल्ट्स के लिए आरंभ करता है।

मुझे अभी तक किसी भी वर्ग के उद्देश्य / संदर्भ के बारे में पता नहीं है, या उनका उपयोग कैसे किया जाएगा। इसलिए मैं खाली क्लास B से ऑब्जेक्ट को इनिशियलाइज़ नहीं कर सकता और यह जाँच सकता हूँ कि इसमें सही मान हैं / सही काम करता है।

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

क्या यहां बेहतर हमला हुआ है?

Comments

मुझे लगता है कि आपने गलत अंत में शुरुआत की है। आपको पहले कोड को समझना चाहिए, फिर परीक्षण करना चाहिए, फिर रिफ्लेक्टर। आप यह जाने बिना कि कोड क्या है, के बारे में बता रहे हैं।

— याकूब रायहेल

@JacobRaihle यह उन सामानों के लोगों के लिए एक विशेष कार्यक्रम है जिन्हें मैंने कभी नहीं छुआ। जैसा कि मैं जाता हूं, मैं संदर्भ उठा रहा हूं, लेकिन मेरे शुरू होने से पहले ठोस समझ बनाने के लिए इंतजार करना व्यावहारिक नहीं है।

— जेटीएम

क्या व्यावहारिक नहीं है चीजों को फिर से लिखना और, जब परिवर्तन उत्पादन में हैं, तो यह पता लगाना कि आपके पास क्यों नहीं होना चाहिए। यदि आप पहले अच्छी तरह से परीक्षण कर पाएंगे , तो ठीक है, यह कोड आधार जानने का एक अच्छा तरीका हो सकता है। यदि नहीं, तो यह जरूरी है कि आप बदलने से पहले समझें।

— याकूब रायहेल

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

— विन्सेन्ट सेवार्ड

आप नहीं पूछ सकता हूँ / यह कोई है जो द्वारा की समीक्षा होने करता है यह समझते हैं?

— pjc50

Answer 1

आप अच्छा कर रहे हैं!

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

हालाँकि, आपके पास पर्याप्त परीक्षण डेटा होना चाहिए और यह सुनिश्चित करना चाहिए कि आपके पास उस घटक के उपयोगकर्ता के दृष्टिकोण से सॉफ़्टवेयर क्या करता है, अन्यथा आपको समझ में आता है, अन्यथा आप महत्वपूर्ण परीक्षण मामलों को छोड़ देते हैं।

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

1. "बाहर से" कोड की समझ प्राप्त करें,
2. प्रतिगमन परीक्षण लिखें,
3. रिफैक्टर, जो कोड के आंतरिक की बेहतर समझ की ओर जाता है

Comments

बिल्कुल सही उत्तर, जैसा कि पुस्तक "वर्किंग विथ लेगेसी कोड" में वर्णित है

— अल्तोयेर

मुझे एक बार ऐसा कुछ करना था। मैं इसे संशोधित करने से पहले एप्लिकेशन से विशिष्ट आउटपुट डेटा एकत्र करता हूं, फिर इसके माध्यम से एक ही परीक्षण डेटा चलाकर एप्लिकेशन के मेरे नए संस्करण की जांच करता हूं। 30 साल पहले ... फोरट्रान ... यह किसी प्रकार की इमेज प्रोसेसिंग / मैपिंग चीज़ थी, इसलिए मैं वास्तव में यह नहीं जान सकता था कि आउटपुट 'इसे देखकर या परीक्षण मामलों को लिखकर' होना चाहिए। और, मैंने इसे टेक्ट्रोनिक्स वेक्टर (लगातार) प्रदर्शन पर किया। सरकारी काम ... 2 तेजली मेरे पीछे से टकराते हुए।

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

— कोडमोंकी

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

— लियोरी

@nocomprende, यह मजेदार है कि मैंने पिछले सप्ताह एक विरासत वैज्ञानिक फोरट्रान 77 कोड के साथ वह सटीक काम किया। एक फ़ाइल में एससीआई डेटा की छपाई जोड़ें, इनपुट और अपेक्षित आउटपुट के साथ परीक्षण निर्देशिकाएं सेट करें, और मेरा परीक्षण मामला आउटपुट के दो सेटों का एक मात्र था। यदि वे चरित्र के लिए चरित्र से मेल नहीं खाते हैं, तो मैंने कुछ तोड़ दिया। जब कोड ज्यादातर दो सबरूटीन्स होते हैं जो प्रत्येक 2-3k एलओसी होते हैं, तो आपको कहीं शुरू करना होगा।

— गोड्रिक सीर

Answer 2

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

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

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

Comments

किसी भी तरह की जानकारी फ्लाइंग ब्लाइंड से बेहतर है। मैं सर्वर प्रोग्राम्स में बग्स का पता लगाता था जो एक क्रैश डंप फ़ाइल (यूनिक्स) पर डिबगर को लागू करके और स्टैक ट्रेस के लिए पूछकर उत्पादन में थे। इसने मुझे उस फ़ंक्शन का नाम दिया जहां गलती हुई थी। किसी अन्य ज्ञान के साथ भी (मुझे नहीं पता था कि इस डिबगर का उपयोग कैसे किया जाए) यह मदद करता है अन्यथा अन्यथा एक रहस्यमय और अपरिवर्तनीय स्थिति होगी।