क्या मुझे सेवा कक्षा के भीतर एक विधि के लिए यूनिट परीक्षण लिखने की आवश्यकता है जो केवल भंडार वर्ग के भीतर एक विधि को कॉल करता है?

उदाहरणक्या मुझे सेवा कक्षा के भीतर एक विधि के लिए यूनिट परीक्षण लिखने की आवश्यकता है जो केवल भंडार वर्ग के भीतर एक विधि को कॉल करता है?

मैं भंडार वर्ग (दाल) है: एक इकाई परीक्षण बनाना MyRepository के लिए ले जाएगा

public class MyService 
{ 
    private IMyRepository localRepository; 

    public MyService(IMyRepository instance) 
    { 
     this.localRepository = instance; 
    } 

    public void Delete(int itemId) 
    { 
     instance.Delete(itemId); 
    } 

    // other methods 
}

public class MyRepository : IMyRepository 
{ 
    public void Delete(int itemId) 
    { 
     // creates a concrete EF context class 
     // deletes the object by calling context.DeleteObject() 
    } 

    // other methods 
}

मैं भी एक सेवा वर्ग (BLL) है इसे लागू करने से कहीं अधिक समय, क्योंकि मुझे इकाई फ्रेमवर्क संदर्भ का नकल करना होगा।

लेकिन MyService के लिए यूनिट परीक्षण बनाना बकवास लगता है, क्योंकि यह केवल रिपोजिटरी में कॉल करता है। मैं जांच सकता हूं कि यह सत्यापित करने के लिए है कि क्या वास्तव में यह रिपोजिटरी हटाएं विधि को कॉल करता है।

प्रश्न

आप इकाई परीक्षण कैसे सुझाव है हटाएँ तरीकों में से इन जोड़ी। दोनों? एक? कोई नहीं? और आप क्या परीक्षण करेंगे?

स्रोत

2009-07-06 Robert Koritnik

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

यह समझने के लिए एक महत्वपूर्ण अवधारणा है। अगर कोई बाद में साथ आता है और आपके सर्विसलेयर को बदलता है, और कोई यूनिट टेस्ट नहीं है, तो आप कैसे सत्यापित कर सकते हैं कि कार्यक्षमता काम जारी रखती है?

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

स्रोत

2009-07-06 18:47:08 Joseph

लेकिन अगर मैं यूनिट परीक्षण सेवा। हटाएं() विधि, तो मैं यह सत्यापित कर सकता हूं कि यह Repository.Delete() विधि को कॉल करता है। मैं किसी भी डेटा की जांच नहीं कर सकता, क्योंकि भंडारण में डेटा हेरफेर किया जाता है। अन्य (भविष्य) जटिलताओं को परीक्षण में शामिल नहीं किया जाएगा। –

@Robert यह पूरी तरह से सही नहीं है। आपको नकली IMyRepository ऑब्जेक्ट बनाना होगा। एक बार ऐसा करने के बाद, आप अपना मॉक सेट अप कर सकते हैं ताकि जब सर्विस लेयर कॉल उस पर डिलीट हो जाए, तो आप यह सत्यापित कर सकते हैं कि मिल्क पर डिलीट को सही तरीके से बुलाया जाता है। इसलिए, आप सेवा का परीक्षण कर रहे हैं। रिपोजिटरी का परीक्षण किए बिना कार्यक्षमता हटाएं। साथ ही हटाएं। – Joseph

हां, दोनों।

IMyRepository mock = ...; 
// create Delete(int) expectation 

MyService service = new MyService(mock); 
service.Delete(100); 

// Verify expectations

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

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

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

स्रोत

2009-07-06 18:45:45

ठीक है आपने जो कुछ किया है वह सब एक सेवा थी। डिलीट() परीक्षण। आपने मेरी रिपॉजिटरी और परीक्षण सेवा का मज़ाक उड़ाया है कि यह वास्तव में भंडार में कॉल करता है। –

मेरी पिछली टिप्पणी के साथ मेरा क्या मतलब था कि आपने "दोनों" कहा लेकिन केवल सेवा परत का परीक्षण करने के लिए कोड लिखा था। लेकिन हाँ, आपके मामले में सेवा का परीक्षण किया जाता है। –

क्षमा करें हाँ, फिर मेरे पास ठोस भंडार का परीक्षण करने के लिए परीक्षणों का एक और सेट होगा, जो शायद अधिक कठिन हो सकता है क्योंकि आप शायद तृतीय पक्ष पुस्तकालयों और अन्य परतों पर निर्भर हैं। वे परीक्षण एकीकरण परीक्षण की तरह अधिक हो सकता है। तो दोनों, कुल कोड कवरेज के लिए प्रयास करें। लेकिन मुझे नहीं लगता कि आप इस वर्ग को अनदेखा कर सकते हैं क्योंकि यह अमूर्त है जिसके खिलाफ आप अपने ऐप को कोडिंग करेंगे। –

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

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

स्रोत

2009-07-06 18:45:59

क्या यह जानना पर्याप्त है कि सेवा। हटाएं() Repository.Delete() कहते हैं? तो आप बस सेवा के साथ ठीक हैं। हटाएं()। क्या आपको डेटा जांचने की ज़रूरत है? फिर डेटा को संशोधित करने के लिए आपको कुछ स्तर के मॉकिंग की आवश्यकता होगी। –

इसके अलावा, अगर आपने टीडीडी के साथ यह कोड बनाया था, तो आपके पास एक परीक्षण होता। यह वास्तव में मायने रखता है कि लोग आपकी सेवा के माध्यम से हटा सकते हैं, इसलिए आपको वास्तव में इसका परीक्षण करना होगा।

स्रोत

2009-07-06 18:47:31

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

स्रोत

2009-07-06 20:08:26 crauscher

मैं चाहता हूं, लेकिन जैसा कि मैं नेट पर Google पर जा सकता हूं, एंटीटी फ्रेमवर्क संदर्भ का मज़ाक उड़ा रहा है ... –

उत्तर

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