इकाई आंतरिक घटकों का परीक्षण

14

आप कक्षा / मॉड्यूल / पैकेज / आदि के आंतरिक / निजी घटकों का परीक्षण किस सीमा तक करते हैं? क्या आप उनका परीक्षण करते हैं या आप केवल बाहरी दुनिया के लिए इंटरफ़ेस का परीक्षण करते हैं? इन आंतरिक का एक उदाहरण निजी तरीके हैं।

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

स्वाभाविक रूप से, आपको बाहरी इंटरफ़ेस को नमूना तार के साथ कॉल करके और हाथ से तैयार आउटपुट के साथ तुलना करके परीक्षण करना चाहिए। लेकिन अन्य प्रक्रियाओं के बारे में क्या? क्या आप यह जांचने के लिए व्यक्तिगत रूप से उनका परीक्षण करेंगे कि वे अपने सबस्ट्रिंग को सही ढंग से पार्स करते हैं?

मैं कुछ तर्कों के बारे में सोच सकता हूं:

पेशेवरों :

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

विपक्ष :

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

आपकी क्या राय हैं?

testing unit-testing test-coverage

— imgx64
स्रोत

के साथ या महत्वपूर्ण ओवरलैप के संभावित डुप्लिकेट: प्रोग्रामर.स्टैकएक्सचेंज.

— com

8

मामला: एक "मॉड्यूल" (एक व्यापक अर्थ में, यानी एक सार्वजनिक इंटरफ़ेस और संभवतः कुछ निजी आंतरिक भागों में भी) इसके अंदर कुछ जटिल / शामिल तर्क हैं। सिर्फ मॉड्यूल इंटरफ़ेस का परीक्षण करना मॉड्यूल की आंतरिक संरचना के संबंध के साथ एकीकरण परीक्षण का एक प्रकार होगा, और इस प्रकार एक त्रुटि पाए जाने पर ऐसा परीक्षण सटीक आंतरिक भाग / घटक को स्थानीयकृत नहीं करेगा जो विफलता के लिए जिम्मेदार है।

समाधान: जटिल आंतरिक भागों को स्वयं मॉड्यूल में बदल दें, उन्हें यूनिट-टेस्ट करें (और यदि वे स्वयं बहुत जटिल हैं तो उनके लिए इन चरणों को दोहराएं) और अपने मूल मॉड्यूल में आयात करें। अब आपके पास बस मॉड्यूल का एक सेट है जो सरलता से परीक्षण करने के लिए पर्याप्त है (दोनों की जाँच करें कि व्यवहार सही है और त्रुटियों को ठीक करें), और यह सब आसान है।

ध्यान दें:

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

[अपडेट करें]

मामलों में कुछ स्मार्ट आंतरिक तर्क का परीक्षण करने के लिए जब ऑब्जेक्ट के आंतरिक भागों को डालना मुश्किल होता है (मेरा मतलब है कि सदस्य निजी तौर पर आयातित मॉड्यूल / पैकेज नहीं हैं) बस वस्तु के सार्वजनिक इंटरफ़ेस के माध्यम से इनपुट को खिलाने के साथ उपयुक्त स्थिति में हैं:

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

— mlvljr
स्रोत

और सूची लेआउट थोड़ा टूटा हुआ प्रतीत होता है;

— mlvljr

1

अच्छा उत्तर। .NET में आप इंटरनल को टेस्ट करने के लिए [assembly: InternalsVisibleTo("MyUnitTestAssembly")]अपने में विशेषता का उपयोग कर सकते हैं AssemblyInfo.cs। हालांकि यह धोखा लगता है।

— कोई भी

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

— mlvljr

2

FSM- आधारित कोड का दृष्टिकोण परंपरागत रूप से उपयोग किए जाने से थोड़ा अलग है। यह हार्डवेयर परीक्षण के लिए यहाँ वर्णित के समान है (जो आमतौर पर एक FSM भी है)।

संक्षेप में, आप एक परीक्षण इनपुट अनुक्रम (या परीक्षण इनपुट अनुक्रमों का एक सेट) बनाते हैं, जो न केवल एक निश्चित आउटपुट का उत्पादन करना चाहिए, बल्कि एक विशेष "खराब" आउटपुट का उत्पादन करते समय विफलता की प्रकृति से विफल घटक की पहचान करने देता है। दृष्टिकोण काफी स्केलेबल है, जितना अधिक समय आप परीक्षण डिजाइन पर खर्च करेंगे उतना बेहतर परीक्षण होगा।

इस प्रकार का परीक्षण "कार्यात्मक परीक्षण" के करीब है, लेकिन यह हर बार जब आप किसी कार्यान्वयन को छूते हैं तो परीक्षण बदलने की आवश्यकता समाप्त हो जाती है।

— bobah
स्रोत

2

अच्छा वह निर्भर करता है :-)। यदि आप एक BDD (व्यवहार प्रवृत्त विकास) या एक ATDD (स्वीकृति परीक्षण संचालित विकास) दृष्टिकोण का अनुसरण कर रहे हैं, तो सार्वजनिक इंटरफ़ेस का परीक्षण ठीक है (जब तक आप इसे अलग-अलग इनपुट के साथ पूरी तरह से परीक्षण करते हैं। अंतर्निहित कार्यान्वयन उदाहरण के लिए निजी तरीके नहीं है। वास्तव में महत्वपूर्ण है।

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

सब कुछ के साथ के रूप में, YMMV

— मार्टिजन वर्बर्ग
स्रोत

1

कोई व्यावहारिक अर्थ के साथ कई भागों में विभाजित है, जैसे ParseQuotedString(), ParseExpression(), ParseStatement(), ParseFile()और उन सब को सार्वजनिक करना। यह कैसे संभव है कि आपका सिंटैक्स इतना बदल जाए कि ये अप्रासंगिक हो जाएं?

— DomQ
स्रोत

1

यह दृष्टिकोण आसानी से कमजोर एनकैप्सुलेशन और बड़ा होता है और इंटरफेस का उपयोग / समझने के लिए कठिन होता है।

— सारा