एक एंटीपार्टर्न इकाई परीक्षण के लिए एकल कार्यान्वयन इंटरफेस हैं?

Question

इकाई परीक्षण के संबंध में, मुझे सिखाया गया था कि उत्पादन कोड में परीक्षण-संबंधित कोड नहीं होना चाहिए।

ठीक है, मुझे लगता है कि जब भी मैं इकाई परीक्षण करने की कोशिश करता हूं तो मैं उस नियम को तोड़ रहा हूं।

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

यह मेरे लिए एक बुरी चीज की तरह लगता है।

मैं, एक सार आधार वर्ग बना सकते हैं या सभी सार्वजनिक तरीकों मैं xyzzy Overridable/virtual पर परीक्षण करना चाहते हैं बना सकता है, लेकिन वह भी गलत लगता है के बाद से xyzzy विरासत के लिए और एक YAGNI नजरिए से नहीं बनाया गया है कभी नहीं होगा से विरासत में रहें।

एक विरोधी-पैटर्न का परीक्षण करने के उद्देश्य से एकल-कार्यान्वयन इंटरफेस बना रहा है? क्या बेहतर विकल्प हैं?

Answer 1

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

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

मैं तरह का क्या स्वरूप है (यह बताता है कि एक implementer यह क्या नहीं है क्या कर सकते हैं,)

मैं अपनी बात यहाँ नहीं मिला क्योंकि इंटरफ़ेस का वर्णन करता है के खिलाफ चले गए हैं वस्तु कर सकते हैं। केवल एक ठोस (उत्पादन) कार्यान्वयन इस संपत्ति को नष्ट नहीं करता है।

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

Answer 2

मेरे अनुभव में, यह .NET विकास का काफी विशिष्ट है, इस तथ्य से निकलता है कि विधि ओवरराइडिंग ऑप्ट-इन आधार पर है; यदि आप निर्भरता का नकल करना चाहते हैं, तो आपको या तो एक इंटरफ़ेस या ऑब्जेक्ट की आवश्यकता होती है जिसका विधियां सभी वर्चुअल हैं।

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

जो भी आप कर रहे हैं वह करते रहें - जो भी पाप आप कर रहे हैं, मेरे विचार में, आपके यूनिट परीक्षण के लाभों से आसानी से बाहर निकल गया है!

Answer 3

हां, यह एक विरोधी पैटर्न है।एक पैटर्न "एक निश्चित संदर्भ में एक आम समस्या का समाधान" होगा। लेकिन इस मामले में, हमारे पास कार्य-आसपास है, समाधान नहीं।

प्रश्न में समस्या को अपनी निर्भरताओं से परीक्षण करने के लिए एक यूनिट को अलग करने की आवश्यकता है, ताकि यूनिट परीक्षणों को लिखते समय उन निर्भरताओं के कार्यान्वयन पर विचार नहीं किया जाना चाहिए। इस समस्या के सामान्य और सही समाधान को "मॉकिंग" कहा जाता है, जहां परीक्षण लेखक मॉक निर्भरताओं से जो भी व्यवहार आवश्यक है, निर्दिष्ट कर सकता है।

इसके विपरीत, डेवलपर को अनावश्यक अलग इंटरफेस बनाने के लिए मजबूर करना, या virtual के रूप में विधियों की घोषणा करना, तकनीकी रूप से अन्य लोगों से एक इकाई को अलग करने में तकनीकी अक्षमता के लिए एक कार्य-आसपास है।

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