2015-04-07 7 views
5

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

+0

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

उत्तर

4

नकली आधारित परीक्षण

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

VerifyAll() वाक्य रचना

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

VerifyAll() प्रत्येक में और हर परीक्षा पद्धति

यह सबसे अच्छा overkill और सबसे खराब है अपने टेस्ट स्वीट को नुकसान हो जाएगा का उपयोग करना।

  • एक सामान्य नियम के रूप में, एक इकाई परीक्षण केवल एक चीज का परीक्षण करना चाहिए। आपके सामान्य दावे के अलावा VerifyAll() को व्यवस्थित रूप से कॉल करना भ्रम लाता है - यदि परीक्षण विफल रहता है तो आप यह सुनिश्चित करने के लिए नहीं जानते कि क्या गलत हुआ।

  • जहां तक ​​पठनीयता है, आप बस अपने प्रत्येक परीक्षण में शोर जोड़ रहे हैं। वास्तव में इसका मतलब है कि VerifyAll() वास्तव में इसका अर्थ है कि यह पता लगाने के लिए एक परीक्षण विधि पढ़ना बहुत मुश्किल है।

  • आप आमतौर पर यह चुनना चाहते हैं कि आप अपने कार्यान्वयन पर डिजाइन दबाव को कहां लगाते हैं और इसे हर जगह अंधेरे से लागू नहीं करते हैं, क्योंकि इसमें रखरखाव मूल्य है।

तो तुम सच में VerifyAll(), बेहतर उपयोग करने के लिए IMO इसके लिए अलग परीक्षण लिखने के लिए है।

0

पसंदीदा तरीका एएए का उपयोग करना है। लेकिन शून्य रिटर्न प्रकार के साथ बाह्य निर्भरताओं के लिए (वर्ड लिखित डेटा (डेटा डेटा) कहें), सत्यापन उपयोगी हो सकता है (या सेटअप, और फिर VerifyAll)।

10

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

public void SendReport(DateTime reportDate, ReportType reportType) 
{ 
    var report = generator.GenerateReport(reportDate, reportType); 
    var reportAsPlainText = converter.ConvertReportToText(report); 
    reportSender.SendEmailToSubscribers(body: reportAsPlainText); 
} 

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

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

एक अंतिम नोट के रूप में, रॉय Osherove अपनी पुस्तक में Art Of Unit Testing (2nd edition) इकाई परीक्षण को तीन श्रेणियों में अलग करती है पर निर्भर करता है, क्या जाँच की जा सकती: (सरल, सामान्य)

  • परिवर्तन विधि के

    • वापसी मान सिस्टम स्थिति (सरल, दुर्लभ)
    • बाहरी घटक को कॉल (जटिल, दुर्लभ) में

    अंतिम श्रेणी wher है ई आप उन पर mocks और Verify विधियों का उपयोग करें। अन्य दो के लिए, स्टब्स पर्याप्त हैं (Setup विधियां)।

    जब आपका कोड सही तरीके से डिज़ाइन किया गया है, तो इस तरह की परीक्षा (अंतिम श्रेणी) आपके कोड बेस में अल्पसंख्यक हो सकती है, कहीं 5% - 10% रेंज (रॉय की पुस्तक से ली गई संख्या, मेरे अवलोकनों के साथ) में।


    : कि फोन करने वाले आसानी से सत्यापित नहीं कर सकते वास्तव में कॉल के बाद happend क्या में के रूप में सर्वनाश।

  • संबंधित मुद्दे