इकाई परीक्षण डेटा संग्रहण

Question

मान लीजिए कि मेरे पास विधियों 'storeData (कुंजी, डेटा)' और 'GetData (कुंजी)' के साथ एक इंटरफ़ेस है। मुझे ठोस कार्यान्वयन का परीक्षण कैसे करना चाहिए? क्या मुझे यह जांचना चाहिए कि क्या डेटा भंडारण माध्यम (जैसे एक एसक्यूएल डेटाबेस) में सही ढंग से सेट किया गया था या क्या मुझे यह जांचना चाहिए कि यह GetData का उपयोग करके सही डेटा वापस देता है या नहीं?

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

Answer 1

मुझे लगता है कि यह बाद में डेटा के साथ क्या होता है इस पर निर्भर करता है - यदि आप केवल storeData और getData का उपयोग कर डेटा तक पहुंचने जा रहे हैं, तो संगीत कार्यक्रम में विधियों का परीक्षण क्यों न करें? मैं एक मौका है कि एक बग पैदा होगा और यह थोड़ा यह पता लगाने की है कि क्या यह storeData या getData में है कठिन हो जाएगा, लेकिन मैं विचार करूँगा कि एक स्वीकार्य जोखिम यह

1. अपने परीक्षण लागू करने के लिए आसान बना देता है, अगर वहाँ है लगता है , और
2. internals को छिपा, जैसा कि आप कहते हैं कि

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

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

Answer 2

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

Const KEY1 = "somekey" 
Const VALUE1= "somevalue" 


Const KEY2 = "somekey2" 
Const VALUE2= "somevalue2" 



Sub SetUpUnitTests() 
{ 
    Insert Into SQLTable(KEY1,VALUE1) 
} 


//this test is not dependent on the setData Method 
Sub GetDataTest() 
{ 
    Assert.IsEqual(getData(KEY1),VALUE1) 
} 

//this test is not dependent on getData Method 
Sub SetDataTest() 
{ 
    storeData(newKey,NewData) 
    Assert.IsNotNull(Direct Call to SQL [Select data from table where key=KEY2]) 

} 

Sub TearDownUnitTests() 
{ 
    Delete From table Where key in (KEY1, KEY2) 
} 

Answer 3

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

Answer 4

संगीत कार्यक्रम में दोनों परीक्षण करना एक आम तकनीक है (कम से कम, मेरे अनुभव में), और मैं इससे दूर नहीं जाऊंगा। मैंने serializing/deserializing और पार्सिंग और मुद्रण के लिए इस पैटर्न का उपयोग किया है।

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

Answer 5

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

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

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